Architecture
Last updated
Last updated
Hypertune is uniquely architected to provide reliability and performance guarantees when you access your feature flags via one of our SDKs.
SDKs make a single network request on initialization to download your flag logic from Hypertune Edge and then evaluate your flags locally, synchronously, in memory with no network latency.
They listen for updates to your flag logic in the background and automatically download any changes which will be reflected in the next flag evaluation.
Analytics for your flags, A/B tests, staged rollouts, multivariate tests, machine learning loops and events are collected by SDKs as you evaluate your flags and then flushed to Hypertune Edge in the background.
Since there's no dependency on the server for each flag evaluation, this greatly improves both reliability and performance.
The single network request to initialize SDKs is made to our CDN edge servers hosted by Cloudflare so there is no direct dependency on our application servers.
SDKs come with a CLI tool to auto-generate a client so you can access your flags with end-to-end type-safety. This ensures typos in flag names or incorrectly passed targeting attributes can be caught at build-time rather than runtime. It also improves the developer experience with code completion, comments, "find all references" and type-safe flag clean up.
You can optionally specify an SDK initialization query to:
Select which flags to fetch
Provide some targeting attributes upfront so that any flag logic that depends on those attributes can be partially reduced on the edge
This is useful for:
Performance
You can limit which flags are fetched to reduce the network payload size
You can partially reduce flag logic on the edge to:
Reduce the network payload size
Reduce the logic that needs to be locally evaluated by the SDK
Security
You can eliminate sensitive logic, e.g. a list of user IDs, on the edge so it doesn't get leaked to publicly accessible clients, e.g. in the browser
To improve reliability, you can include a fallback snapshot of your flag logic in the generated client at build time. The SDK will instantly initialize from the snapshot first before fetching the latest flag logic from Hypertune Edge.
You can keep the snapshot fresh by setting up a webhook to regenerate the client on every Hypertune commit. In this case, you don't need to initialize from Hypertune Edge at all, eliminating network latency and bandwidth, improving both performance and efficiency.
The snapshot is particularly useful for single-page apps (SPAs) as you can use your flags in the first app render without any page load delay, UI flicker or layout shift.
It also enables using Hypertune in local-only, offline mode, e.g. for running unit tests or in isolated, secure, air-gapped environments.
Whenever you evaluate a flag, you pass a hard-coded fallback value, e.g.
If Hypertune Edge is unreachable and there's no build-time fallback snapshot of your flag logic, or there's an error evaluating the flag, you'll get this hard-coded fallback value instead.
This ensures that in the worst-case scenario, your app still works properly.
You can hydrate or "bootstrap" the SDK in the browser with the state of the SDK on your server so you can use your flags in the first app render without any page load delay, UI flicker or layout shift.
This works well with server-side rendering frameworks like Next.js, Nuxt, Remix and Gatsby.
You can disable server initialization and use a build-time fallback snapshot of your flag logic to use SDKs in local-only, offline mode. This is useful for running unit tests or using Hypertune in isolated, secure, air-gapped environments.
You can define targeting attributes at the:
root level
individual flag level
And provide them during:
SDK initialization
local flag evaluation
a mix of both
Typically, you'll provide targeting attributes when locally evaluating the root flag, passing it the context argument you defined in your schema. You'll get back the Root SDK node which will have type-safe methods to evaluate all your individual flags.
You can also provide flag-specific targeting attributes when evaluating individual flags.
SDKs evaluate flags locally, synchronously, in memory with no network latency. This includes flag logic that contains A/B tests, machine learning loops and analytics event logging.
So you can use an SDK on the backend to evaluate flags, including A/B tests, for different users without adding latency to every request.
And you can use an SDK on the frontend to evaluate flags, including A/B tests, without blocking renders.
SDKs send logs to Hypertune Edge in the background. This allows you to:
See how often different parts of your flag logic are evaluated, e.g. to see how often different targeting rules are evaluated and passed in realtime
Log analytics events
Log split exposures, e.g. for A/B tests, multivariate tests and machine learning loops
See any SDK errors from the Hypertune UI
You can also manually trigger and wait for logs to be flushed.
SDKs listen for updates to your flag logic in the background. When you save and activate a new commit from the Hypertune UI, the SDK will fetch your new flag logic and use it on the next evaluation.
You can also manually trigger and wait for a re-initialization from the server.
And you can add and remove listeners to be notified of updates, e.g. to trigger a re-render on the frontend after an update.
Hypertune SDKs have been uniquely architected to work optimally in serverless and edge environments like:
Vercel deployments
Cloudflare Workers
AWS Lambdas
Google Cloud Functions
Netlify Functions
DigitalOcean Functions
If you deploy on Vercel, you can initialize the SDK with near-zero latency in Vercel's edge environment when you set up our Vercel Edge Config integration.
By default, SDKs output info and error logs to the console. But you can provide a custom logging callback to capture and forward logs elsewhere, e.g. to your monitoring infrastructure.
You can shut down an SDK to cleanly stop all its background processes and terminate all its connections.
All of your flags are versioned together in the single Git-style version history of your project.
New changes create commits.
You can review diffs of your changes before saving them, as well as diffs of historical commits.
You can create branches and configure the SDK and code generation to use a specific branch.
You can merge branches with pull requests.
And you can safely onboard nontechnical team members by assigning them the Contributor role so that any changes they make create a pull request that needs to be reviewed.
