SDK
When SDKs initialize from Hypertune Edge, some arguments can be provided in the GraphQL query so that your configuration logic can be partially reduced on the server. The rest of the logic is evaluated locally by the SDK when client code calls its methods with the remaining arguments.
This is useful when using the SDK on the frontend as you can eliminate sensitive logic like lists of user IDs on the server so that they don't get leaked to the browser.
It also improves performance as the network payload is smaller and less logic needs to be evaluated on the client.
After initialization, the SDK evaluates your configuration logic locally, in-memory, with no network latency. So you can use the SDK on your backend to evaluate flags for different users without adding latency to every request. And you can use it on the frontend without blocking renders.
The SDK listens for updates to your configuration logic in the background. When you save and activate a new commit, it fetches your new logic and uses it on the next evaluation.
By default, this is disabled when using the SDK on the frontend.
SDKs comes with a command line tool that auto-generates type-safe code based on your initialization query. These are type-safe wrappers around the core SDK methods that traverse, reduce and evaluate your configuration logic.
Every time you run code generation, a snapshot of your configuration logic is embedded in the generated code.
The SDK initializes from this snapshot first, before fetching the latest configuration logic from the server.
So even in the unlikely event that Hypertune Edge is unreachable, the SDK will still initialize and work properly.
You can also keep your build-time snapshot up to date with a commit webhook.
This is particularly useful on static Jamstack sites and other frontends when you need to evaluate configuration logic before the first render, as this can happen instantly without blocking page load or resulting in a UI flicker.
If there's an error evaluating your configuration logic, the SDK will use the hard-coded fallback value that you provide with every evaluation.
The SDK maintains a local queue of logs which it periodically flushes to the backend in the background so you can see how often different parts of your flag logic are called, e.g. to see how many sessions fall into each targeting rule, as well as analytics for your events, A/B tests and machine learning loops.
You can pin your SDK to a major version of your schema so that if you make a breaking change that bumps the major version (like removing a field), it will continue to initialize from the latest commit for the old schema version, until you re-run code generation and update the pinned version.
Last modified 1mo ago