Frontend Feature Flags vs Backend Feature Flags

Does it matter whether you evaluate feature flags on the backend or the frontend? The answer is yes. As you might have guessed, the frontend and backend are distinct components of software architecture—and the factors we consider when working with them, such as security and control, apply to feature flags as well.

In this article, we'll explore the pros and cons of backend and frontend feature flags and solutions to challenges you may face while working with them.

What are Feature Flags?

Feature flags, also known as feature toggles, are powerful tools in modern software development that let you turn features on or off without redeploying your code. Feature flags could be used for gradual feature rollouts, separating deployments from releases, A/B testing, and pretty much any situation where you want to reduce the risks of feature releases.

In practice, feature flags look something like this:

isCoolNewFeatureEnabled = getFeatureFlag("cool-new-feature")
if(isCoolNewFeatureEnabled) {
    // do the new thing
} else {
    // do the old thing
}

To assign a feature flag to a feature in your app, you'll need to wrap the feature in an if-statement that depends on the flag's value. When the feature flag is enabled, the feature or functionality will be available in the app.

Feature flags can be managed and stored in various ways, but the simplest approach is to use a feature management platform like ConfigCat. Such platforms provide a user-friendly interface to create, toggle, audit, and remove feature flags as needed.

Feature flags can be configured with targeting rules and/or percentage options to deliver features to specific user segments. For example, you could use a feature flag to control the pricing tiers of a software product based on a user's location.

The process of determining a feature flag's value is called evaluation. The context in which this evaluation happens is what distinguishes frontend (client-side) feature flags from backend (server-side) feature flags.

info

If you're looking for solutions to common challenges with frontend and backend feature flags, feel free to skip ahead to the Working Around the Challenges section of this article.

Frontend Feature Flags

Frontend feature flags are used to control the user interface and user experience of an application. Frontend feature flags can manage access to premium features, subscriptions, or other monetization strategies. Examples include toggling price tags during sales events, displaying different versions of a landing page, showing features based on a user's country, etc.

Pros

• Easier to implement because the features they control are close to the user and have a visual impact.
• Simpler to debug and straightforward to remove when they are no longer needed.
• Involve less code, as developers only need to wrap the feature's UI components in conditional statements. They also won't need to write HTTP requests to fetch the feature flags from an API.

Cons

• A slow internet connection might cause browsers to download feature flags slowly, leading to a brief flash of content that should be hidden behind a feature flag.
• Users may be able to view sensitive information in a feature flag's targeting rule through a browser's Devtools.

Backend Feature Flags

Backend feature flags are evaluated on the server-side. Common use cases include modifying system behavior, such as API rate limiting, blue-green deployments, database migrations, or implementing kill switches for misbehaving features. A kill switch is a critical tool that allows teams to quickly disable problematic features if issues arise, thus maintaining stability and preventing major disruptions to the user experience.

Backend feature flags can sometimes control client-facing features through frameworks like Rails and Laravel or by providing an API for the client side to fetch flag values. This approach is especially useful for scenarios where client-side evaluation is not feasible. Backend feature flags can also be gradually released to larger user groups incrementally, minimizing risks associated with software releases by enabling quick adjustments and ensuring that new functionalities perform reliably before reaching a broader audience.

Pros

• Backend feature flags keep evaluations secure on the server-side and reduce the risk of exposing information in the browser.
• Latency is less of a problem here since developers can easily configure fallbacks and make the backend fail more gracefully.
• They also allow for centralized control, making them ideal for features that depend on complex business logic or require consistency across different client platforms.

Cons

• Because the code for backend flags is separate from the frontend code they affect, developers may easily forget the purpose of the flags over time.
• In architectures where multiple client-side frameworks rely on server-side evaluations, any errors at the server level can impact all connected clients.
• Developers need to write additional code to handle HTTP requests because backend feature flags require communication between the client-side and server-side. This extra layer of interaction adds complexity, as developers need to implement and maintain the necessary APIs or endpoints to support this process.

info

The points mentioned in this article apply to most feature management tools since they work in similar ways. However, there may be slight differences depending on the architecture of the feature management tool you use.

Working Around the Challenges

Let's explore a few ways to handle the challenges we mentioned earlier.

Frontend

• To avoid leaking sensitive data, consider using a backend flag and access it through an API on the frontend. If you're using ConfigCat's feature management platform, you can use confidential text comparators to hash your targeting rules so they're not readable in the browser. Though ConfigCat's SDK keys are visible in browsers, they're read-only and can't be used to modify feature flags.
• Consider using animations, loading states, and other techniques to hide features while the feature flags are downloading. This point is more important when you're running experiments because users interacting with multiple variations at once will affect the results.
• To avoid flashing content, consider using modern frameworks (like Next.js or SvelteKit) that support server-side rendering or backend frameworks like Django and Laravel that can generate web pages on the server by default.

Backend

• Consider using templates provided by server-side frameworks (e.g., Blade, ERB, Jinja2), as these mimic the visual simplicity of frontend feature flags by keeping the logic for displaying the feature flag closer to the UI, while also offering the advantages of backend feature flags.

Both (Frontend and Backend)

• For increased security and reliability, consider using ConfigCat Proxy to host an evaluation backend in your infrastructure. With the proxy, you can use external caching solutions like Redis and MongoDB and stream feature flag changes with Server-Sent Events (SSE). Plus, you won't have to write a custom API to serve feature flags to the frontend.
• Cache feature flags, but don't forget to update them so they don't become stale. ConfigCat caches feature flags automatically and allows you to configure how often you want to update them.
• Use reasonable default values for your feature flags that your app can fall back to when facing network issues.

General Best Practices

• Give your feature flags detailed names that describe their purpose, where they'll be used, and for how long. Check out this feature flag naming guide for more.
• Have a system in place to remove unused flags. Tools like ConfigCat’s zombie flag reports and code references can help track and remove stale flags.

Conclusion

I hope you now have a well-rounded view of frontend and backend feature flags. Keep in mind that the suggestions here are not fixed rules, and ultimately, you'll have to choose what works best for you and your users.

If you're in the market for a feature management platform, check out ConfigCat. You can start with the forever free plan, which has all the features you'll need at a small scale.

You can stay up-to-date with ConfigCat on Facebook, X, GitHub, and LinkedIn.