.png%3Falt%3Dmedia%26token%3Db44692e5-25a4-4ca0-b9e0-75a83780c05d)
.png%3Falt%3Dmedia%26token%3Db44692e5-25a4-4ca0-b9e0-75a83780c05d)
Comment on page
Architecture
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, 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 and Fastly 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
The SDK will locally, reliably and instantly initialize from the snapshot first, before fetching the latest flag logic from Hypertune Edge. So even in the unlikely event that Hypertune Edge is unreachable, SDKs will still successfully initialize from the snapshot.
This is useful on the frontend as you can use your flags in the first app render without any page load delay, UI flicker or layout shift.
It's also useful for running an SDK in local-only, offline mode for unit tests.
The snapshot can be kept fresh by setting up a webhook to automatically regenerate it on every Hypertune commit, then committing the result to your own repo.
Whenever you evaluate a flag, you pass a hard-coded fallback value.
If Hypertune Edge is unreachable and there's no build-time fallback 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 "bootstrap" an SDK from your own server. If you use an SDK on your backend, you can pass the state of the SDK to the client, e.g. the browser, and then instantly initialize the SDK on the client with this state.
This is particularly useful for server-side rendering, e.g. with Next.js, as you can initialize the SDK and use your flags in the first app render on the client without any page load delay, UI flicker or layout shift.
You can define targeting attributes at the:
rootlevel- 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.SDKs evaluate flags locally, synchronously, in-memory with no network latency. This includes flag logic that contains A/B tests, machine learning loops and 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 called, e.g. to see how often different targeting rules are evaluated and passed in realtime
- Log events and exposures for your A/B 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.
Hypertune SDKs have been uniquely architected to work optimally in serverless environments, e.g. Vercel deployments, Cloudflare Workers, AWS Lambdas, etc.
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.
Last modified 1mo ago