Feature flags and A/B testing at the edge with Hypertune, Next.js and Vercel

For the last decade, feature flag systems have worked the same.

You install an SDK and when your backend instance boots up, the SDK downloads the logic of all your flags upfront, then listens for updates. That way, you can evaluate flags for different users with the SDK all locally, in memory, so there’s no additional network latency.

Otherwise, without the SDK bootstrapping and syncing, you’d have to make a network request to the feature flag service every time you wanted to evaluate a flag for a specific user. That results in unnecessary network latency, puts more load on the service and has more opportunities for errors.

It also makes it hard to use flags in your code. You can’t evaluate one flag then evaluate another depending on the result of the first as this would require two sequential round trips and that’s unacceptable. So you’re forced to batch requests for flags at the start of a code path.

This might work for you in the short term, but it eventually breaks when you start to need flag analytics and A/B testing.

At a certain scale, it’s useful to see analytics on your flags, e.g. to see how many times it was on vs. off or how many users pass each of your flag’s targeting rules. That way you can quickly verify your flag is set up correctly. But if you always evaluate the flag at the top of your code hierarchy and not deep in the hierarchy where you actually need to check it, the analytics won’t be accurate.

It’s also useful to include an A/B test in your flag logic, e.g. to measure the impact a new feature has on business, product and system metrics. But again, if you evaluate the flag too early, and not where you actually decide to show the feature, then you’ll include too many users in your A/B test, who would never have had a chance to see the feature. This dilutes your test results, making it harder to get a statistically significant result.

So you eventually need an SDK to locally evaluate flags. And that’s what feature flag and A/B testing providers have been offering for the past decade.

Here’s what this common architecture looks like:

This has historically worked great.

Until the arrival of serverless and edge computing.

Today, backend apps are being replaced with small functions that get executed on the edge. Instances are quickly spun up to handle incoming requests and then quickly spun back down. They often have a lifetime of only a few seconds.

This throws a spanner in the works.

Before, backend instances were long-lived so the vast majority of requests would happen when the feature flag SDK was already initialized.

But with short-lived instances, a big fraction of requests now happen when the SDK hasn’t had a chance to initialize. These requests have to wait for SDK initialization which adds latency and defeats the original purpose of the SDK.

To solve this, we need a way to initialize the SDK on these short-lived instances with near-zero latency.

Enter Vercel Edge Config.

Vercel has built Edge Config, a JSON store with near-zero latency lookups when queried from their edge environment.

We’ve built an integration to push all of your feature flag, A/B testing and app configuration logic to Edge Config so that you can initialize the Hypertune SDK instantly.

So far, we’ve assumed the Client is a simple backend server or a frontend app.

And historically, there’s been a clean divide between the two.

But with Next.js, the new App Router paradigm and React Server Components, the line between the server and the client is becoming blurry.

Developers expect the same code to “just work” whether it’s running on the server or the client, and they expect the client to seamlessly “pick up” from where the server left off.

Feature flag and A/B testing systems today haven’t been designed with this in mind.

You typically need to install one SDK for the server and a different one for the client. You have to remember to use the right SDK depending on where your code is running. And the client SDK has to re-initialize from scratch — it doesn’t just “pick up” from where the server left off. So it’s out of sync with the main page load and you often get UI flickers when your flags finally load.

We’ve solved these problems at Hypertune too. The TypeScript SDK works seamlessly on both the server and the client. And you can instantly initialize the SDK on the client with the server response so you never get any UI flicker.

Next.js and Vercel have dramatically changed the landscape of modern web app development. Instead of long-lived backend servers, we have short-lived serverless instances. And instead of frontends and backends being built separately, they’re built together with shared code and tightly integrated data flows.

At Hypertune, we’ve built the most flexible platform for feature flags, A/B testing, analytics and app configuration, designed to work seamlessly with this new stack. Give us a try – you can get started by deploying our Vercel template in one click.