Hypertune
  • Introduction
  • Getting Started
    • Set up Hypertune
    • Next.js (App Router) quickstart
    • Next.js (Pages Router) quickstart
    • React quickstart
    • Remix quickstart
    • Gatsby quickstart
    • Vue quickstart
    • Nuxt quickstart
    • Node.js quickstart
    • React Native quickstart
    • JavaScript quickstart
    • Python quickstart
    • Rust quickstart
    • Go quickstart
    • Web quickstart
    • GraphQL quickstart
  • Example apps
    • Next.js and Vercel example app
  • Concepts
    • Architecture
    • Project
    • Schema
    • Flag lifecycle
    • Logic
    • Variables
    • Splits
    • A/B tests
    • Staged rollouts
    • Multivariate tests
    • Machine learning loops
    • Events
    • Funnels
    • Hypertune Edge
    • Reduction
    • SDKs
    • GraphQL API
    • Git-style version control
    • App configuration
  • Use Cases
    • Feature flags and A/B testing
    • Landing page optimization
    • In-app content management
    • Pricing plan management
    • Permissions, rules and limits
    • Optimizing magic numbers
    • Backend configuration
    • Product analytics
  • Integrations
    • Vercel Edge Config integration
    • Google Analytics integration
    • Segment integration
    • Webhooks
      • Creating webhooks
      • Handling webhooks
  • SDK Reference
    • Installation
    • Type-safe client generation
    • Initialization
    • Build-time logic snapshot
    • Hard-coded fallbacks
    • Local-only, offline mode
    • Hydrate from your own server
    • Wait for server initialization
    • Provide targeting attributes
    • Local, synchronous evaluation
    • Remote logging
    • Getting flag updates
    • Serverless environments
    • Vercel Edge Config
    • Custom logging
    • Shutting down
Powered by GitBook
On this page
  • Overview
  • Auto-generated, type-safe client
  • Initialization
  • Build-time fallback snapshot of flag logic
  • Hard-coded fallbacks
  • Hydrate or "bootstrap" from your own server
  • Local-only, offline mode
  • Provide targeting attributes
  • Local, synchronous, in-memory flag evaluation
  • Sending logs
  • Getting flag updates
  • Serverless environments
  • Vercel Edge Config
  • Custom logging
  • Shutting down
  • Git-style version control
  1. Concepts

Architecture

PreviousNext.js and Vercel example appNextProject

Last updated 9 months ago

Overview

Hypertune is uniquely architected to provide reliability and performance guarantees when you access your feature flags via one of our .

SDKs make a single network request on initialization to download your flag from 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, , , , and 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.

Auto-generated, type-safe client

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.

Initialization

You can optionally specify an SDK initialization query to:

  • Select which flags to fetch

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

Build-time fallback snapshot of flag logic

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.

Hard-coded fallbacks

Whenever you evaluate a flag, you pass a hard-coded fallback value, e.g.

const exampleFlag = hypertune.exampleFlag({ fallback: false });

This ensures that in the worst-case scenario, your app still works properly.

Hydrate or "bootstrap" from your own server

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.

Local-only, offline mode

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.

Provide targeting attributes

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

Local, synchronous, in-memory flag evaluation

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.

Sending logs

  • 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

  • See any SDK errors from the Hypertune UI

You can also manually trigger and wait for logs to be flushed.

Getting flag updates

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.

Serverless environments

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

Vercel Edge Config

Custom logging

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.

Shutting down

You can shut down an SDK to cleanly stop all its background processes and terminate all its connections.

Git-style version control

Provide some targeting attributes upfront so that any flag logic that depends on those attributes can be on the edge

To improve reliability, you can include a fallback snapshot of your flag logic in the at build time. The SDK will instantly initialize from the snapshot first before fetching the latest flag logic from .

You can keep the snapshot fresh by setting up a 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.

If 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.

Typically, you'll provide targeting attributes when locally evaluating the root flag, passing it the context argument you defined in your . You'll get back the Root SDK node which will have type-safe methods to evaluate all your individual flags.

You can also provide when evaluating individual flags.

SDKs send logs to in the background. This allows you to:

Log

Log exposures, e.g. for , and

If you deploy on Vercel, you can initialize the SDK with near-zero latency in Vercel's edge environment when you set up our .

All of your flags are versioned together in the single of your project.

New changes create .

You can review of your changes before saving them, as well as diffs of historical commits.

You can create and configure the SDK and code generation to use a specific branch.

You can merge branches with .

And you can by assigning them the so that any changes they make create a pull request that needs to be reviewed.

generated client
Hypertune Edge
webhook
Hypertune Edge
schema
Hypertune Edge
analytics events
split
A/B tests
multivariate tests
machine learning loops
Vercel Edge Config integration
SDKs
logic
Hypertune Edge
A/B tests
staged rollouts
multivariate tests
machine learning loops
events
Git-style version history
commits
diffs
branches
pull requests
safely onboard nontechnical team members
Contributor role
flag-specific targeting attributes
partially reduced