Feature Flags component

[nikneem]

Overview

​Introduce a new Dapr building block (or an extension of the existing Configuration API) specifically for Feature Flags. This component would provide a standardized way to fetch toggles, evaluate targeting rules, and receive real-time updates without depending on provider-specific SDKs (e.g., LaunchDarkly, Azure App Configuration, Flagsmith).

Problem

​Modern microservices rely heavily on feature flags for progressive rollouts and A/B testing. However:
​SDK Bloat: Each provider requires a unique SDK, increasing binary size and maintenance.
​Complexity: Managing local overrides vs. cloud-hosted flags varies across environments.
​Performance: Developers have to manually manage caching and polling logic to avoid high-latency calls to flag providers.

​# Solution
​Create a Feature Flag Component Interface that supports:
​Boolean & Multivariate Flags: Standardized response types.
​Targeting Context: Ability to pass metadata (User ID, Region, etc.) for server-side or sidecar-side evaluation.
​Real-time Updates: Integration with Dapr’s subscription model to push flag changes to the application.

[tomflenner]

I'd strongly recommend making this compatible with OpenFeature if this feature moves forward.

To simplify provider integrations, consider leveraging the OFREP protocol. Most OpenFeature SDKs already include an OfrepProvider, which would allow to create a Dapr-branded provider by wrapping the existing OfrepProvider. This is a common and proven pattern in the ecosystem.

For example, GoFeatureFlag uses this approach for their SDK providers. You can see their implementation here:
https://github.com/open-feature/dotnet-sdk-contrib/blob/main/src/OpenFeature.Providers.GOFeatureFlag/OpenFeature.Providers.GOFeatureFlag.csproj

This approach would give users immediate access to the OpenFeature ecosystem while maintaining a Dapr-specific provider interface.