On Balance: Client and Server-Side Evaluation

When it comes to feature flags, there are several different approaches to evaluation. This article explains the costs and benefits of each approach.

Who is Split Software?

Split Software is a market leading feature delivery platform. This includes more than a dozen supported languages; twice as many integrations with popular tools like Segment, mParticle, and Google Analytics; and an experimentation engine that produces statistically significant impact analysis.

What does client and server-side evaluation mean?

When you evaluate a feature flag, you’re asking “For this user (and maybe some data about them), should the feature flag be on or off?”

In practice, “on” or “off” doesn’t have to be binary at all. But the basic principal is the same. You ask Split, “Should I give this user the feature?” and Split answers appropriate to the rules you’ve set.

Client-side evaluation is when this question is asked from a browser or mobile device, like Chrome, Android or iOS. Server-side evaluation is when you ask this question on the backend, usually with languages like Python, Go, or node.js

Split supports both.

Most vendors only support server-side evaluation. While flexible, it misses some key capabilities that client-side evaluation provides. In practice, many customers will take a hybrid approach.

Let’s explore client-side evaluation some more…

Client-side Evaluation

To accomplish client-side evaluation, Split SDK downloads the feature flags to the device. This has a cost (in milliseconds), but it’s mitigated by virtue of flag data being hosted at the Fastly CDN. This guarantees a low latency pull from locations around the globe. The flag data can also be cached by the client for a faster startup on second, third, fourth visit, etc. You can even declare a filter at the client to limit which flags you download, though benchmarks have shown that number of flags is not significant.

Why take the hit up front? The primary reason is that flag evaluation can become an activity local to the client (browser or mobile device). There is no network transaction associated with evaluating a Split flag. If you must rely on the backend for feature flag evaluation, you either have chatty network activity or you evaluate everything in batch during render, ruining your experiments (more about this in a moment).

If you’re client is evaluating locally, you get more than just network benefits. You can also keep any user data private and secure. For example, a flag that checks the user’s age can provide the Split SDK with this very private information and Split will use it only to evaluate the flag, and never send it to the Split cloud. This makes client-side evaluation popular with organizations that care about privacy.

“Wait,” you say, “…you could just evaluate that private data on the server-side.” That’s true, but you miss out on other client-side benefits. Keep reading, but first a little more about server-side evaluation.

Server-side Evaluation

Server-side evaluation is like client-side, but it can be faster. Split ships a dockerized Split Synchronizer that can pull feature flag data into a Redis instance or cluster. Then, server-side SDK can use Redis instead of the CDN used by client-side. This yields lightning fast serverless functions and the like, making server-side evaluation the approach of choice for customers that are flagging code on the backend.

What are the other differences then?

Client-side Evaluation for Experiments

Some applications are a simple sheet of controls and content. This is rare, however, as modern applications can feature complex hierarchies of content and controls. Think of an app that has a main page with some arrows on it to show more content and controls, like a dashboard with a section for setting up alerts. The alerts are out of view when the dashboard loads.

If you’re using feature flags with such an app, you might want to flag a new feature in the alert controls. In theory, either client or server-side evaluation will work. There is a practical problem though. Namely, if you have ten thousand users load your dashboard, only one thousand of them might look at the alert controls. The ten thousand are “top of the funnel”, and the alert control display’s one thousand are “bottom of the funnel”.

If you evaluate on the server-side, you will probably just render all the flags on the page before you send it to the user. If you do, you have effectively said, “Ten thousand users saw the alert control!” and now your experiment results are watered down and incorrect. If you wait to evaluate the flag until the user looks at the alert control, the experiment sees just the one thousand users that actually saw the feature and you’re truly looking at impact. The client-side evaluation can accomplish this readily.

This may seem like a small thing, but the pernicious erosion of your imact analyses will result in misdirected feature decision making. You could try to do just-in-time evaluation at the server, but the network becomes very chatty and you’re essentially re-implementing Split’s client-side architecture. Why not just use a battle-tested, performant one?

And now, for something completely different…

Split has a third option. The Split Evaluator The Evaluator is a RESTful wrapping of the Split SDK such that a client can avoid using an SDK entirely. Instead, the clients use an HTTP client, available in virtually every language, to “curl” an HTTP get from the Evaluator. You’re still asking, “should this user get the flag?” but you’re asking on port 80 in HTTP and getting back a JSON response. The Evaluator is popular with customers that don’t have or don’t want to put an SDK into their application.

In the context of our discussion, the Evaluator could be called from either the server or the client side. A single transaction can return evaluations for many flags in batch. You can easily scale Evaluator instances behind a load balancer and deploy them in various, network-friendly locations.

To return to the main discussion…

On Balance: which one do I choose?

The answer is whichever best fits your requirements. In some situations, you’ll want to stick with server-side evaluation, while in others the flexibility of client-side evaluation is necessary to limit network chatter and enhance experimentation ability.

Humbly, it is essential that both options are available, and you should seek out vendors that do both. The Evaluator is extra credit.

A final note…

To do client-side evaluation, you need to download the flag data.

In principle, a malicious third party could learn something interesting from flag rules. “Hey, they’re giving this feature to thirty-something mac users in Peoria!” Or, simply, “What’s this new feature I can’t see?”

First, 95%+ of feature flags are just against the user id, or key as Split calls it. We can answer if a flag is on or off with no more data than that. This means that most flags, if named appropriately, will have nothing to reveal to a third party.

“Named appropriately” is best explained with an analogy. When Tom Cruise is filming Mission Impossible XIX, he doesn’t have signs up on the street saying that they’re filming Mission Impossible. The signs all say, “Now filming Terms of Endearment 3” and the production traffic keeps sliding right on by. If this seems like a hassle, consider that the feature flag names show up in client-side code, even if the evaluation is going to be on the server-side. Server-side evaluation has to make a network call from the client-side, and it does it with the flag name. Exposure is exposure, so if this is a concern you should name your flags appropriately.