Comment on page
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.
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:
This is useful for:
- 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
- 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.
Whenever you evaluate a flag, you pass a hard-coded fallback value.
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:
- 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
rootflag, passing it the
contextargument you defined in your schema. You'll get back the
RootSDK 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.