Feature flag evaluation methods: Remote, Local, or Proxy – what’s right for you?

Trying to figure out the best way to evaluate feature flags for your application? Whether you’re working on a frontend app, a backend service, or something in between, choosing the right evaluation method is crucial. You’ve probably come across a few options—remote evaluation, local evaluation, or even using a proxy—but which one should you go with?

Each of these methods has its pros and cons, and the right choice depends on your app’s performance needs, data privacy concerns, and how your architecture is set up. In this article, we’ll break down each method, explain when to use them, and help you decide which one is the best fit for your situation.

Remote evaluation using the API

Remote evaluation means making an API call to check the value of a feature flag at runtime. This approach is ideal for situations where your frontend application or backend service can afford to make a quick API call whenever it needs to evaluate a flag.

When to use it:

• Frontend applications: If your app is running in a browser or a mobile device, remote evaluation is often the best option. It ensures you’re working with the most up-to-date flag values without needing to store and manage them locally.
• Backend services: For backends that don’t have strict performance constraints and can afford the slight delay of an API call, remote evaluation works great. It’s simple to set up and doesn’t require managing flag data on your servers.

Pros:

• Up-to-date flags: Every time you make an API call, you’re fetching the latest version of your flags.
• Simple to implement: No need to store or manage flag data on your end. The API handles it for you.

Cons:

• Latency: Every evaluation requires an API call, which can introduce a small delay—something to consider for time-sensitive applications.
• Network dependency: You’re relying on a network connection and the availability of the API, which could be a concern in case of network issues or outages.

For more details on how remote evaluation works and how to set it up, check out the remote evaluation documentation.

Local evaluation: evaluating flags locally

Local evaluation is when you evaluate feature flags directly within your application without making an external API call. This method is perfect for scenarios where you need fast, reliable performance, such as backend services or edge computing environments.

When to use it:

• Backend services: If your backend can’t afford the overhead of making API calls for every flag evaluation, local evaluation is the way to go. It ensures you can evaluate flags instantly, without worrying about latency or network issues.
• Edge environments: If you’re running code at the edge (e.g., close to the user or device), local evaluation makes sure flag checks are fast and efficient, which is critical for real-time interactions.

Pros:

• No latency: Since there’s no API call involved, flags are evaluated instantly.
• No network dependency: You don’t need to rely on an external API, which makes your system more resilient to network outages or slowdowns.

Cons:

• Managing flag data: You’ll need to handle syncing and storing the latest flag data locally, which adds complexity to your setup.
• Potential for stale data: If the flag data isn’t updated frequently enough, there’s a risk of working with outdated flags.

To learn more about local evaluation and how to implement it, check out the local evaluation documentation.

Using a Proxy for evaluation

Using a proxy involves setting up a proxy server between your application and the feature flag provider. This allows you to evaluate flags on your own infrastructure while keeping data secure and under your control. It’s a great alternative to server-side evaluation if data privacy is a top concern.

When to use it:

• Data privacy concerns: If you need to ensure that all data stays within your infrastructure (e.g., for compliance reasons), using a proxy keeps everything on your servers while still enabling flag evaluations.
• Server-side applications: For backend applications that can benefit from offloading the feature flag evaluation to a proxy server, this option can help balance performance and data privacy.

Pros:

• Data stays on your servers: No need to send sensitive data over the network to an external API. Everything stays within your infrastructure.
• More control: You manage the proxy, giving you full control over performance, security, and how evaluations are handled.

Cons:

• Complex setup: Setting up and maintaining a proxy adds complexity to your infrastructure. You’ll need to ensure the proxy is always up-to-date and synchronized with the latest flag data.
• Potential bottleneck: If not managed properly, the proxy could become a performance bottleneck, especially under heavy traffic.

For more information on setting up and using a proxy for feature flag evaluation, refer to the proxy documentation.

Conclusion

Choosing the right feature flag evaluation method can have a big impact on your application's performance, scalability, and security. Whether you’re building a frontend app, managing backend services, or dealing with data privacy concerns, there’s an evaluation method that suits your needs:

• Remote evaluation is perfect for frontend applications and backend services that can handle API calls and want the simplicity of real-time flag updates.
• Local evaluation is ideal for backends and edge environments where speed is critical, giving you fast flag evaluations without relying on a network connection.
• Using a proxy offers a great balance for teams focused on data privacy, keeping all flag evaluations within your own infrastructure while still allowing for flexibility.

Ultimately, the right choice depends on the specific needs of your application, the architecture you’re working with, and how much control or simplicity you require. If you’re still unsure, it’s worth evaluating which trade-offs—like latency, data privacy, or complexity—matter most to your team.