Flags as Code

The Flags SDK is conceptually different from the SDKs of most feature flag providers. It puts a few constraints in place that lead to a better experience when using flags.
Using the SDK of a typical feature flag provider looks similar to the code example below, where the SDK is called with the name of the feature flag as a string:
Compare this to what it looks like when using a feature flag in the Flags SDK:
Using a feature flag first requires declaring it like so:
Turning each feature flag into its own function means the implementation can change without having to touch the call site. It also lets you use your well-known editor shortcuts like "Find All References" to see if a flag is still in use.
Each feature flag's declaration can contain the default value. This value is used in case the feature flag can not be evaluated. Containing the default value on the declaration means it will be consistent across all evaluations.
Traditional feature flag SDKs require passing in the context on the call site, as shown below:
The downside of this approach is that every call site needs to recreate the evaluation context. If the evaluation context is created differently or not provided, the feature flag may evaluate differently across the codebase.
The Flags SDK does not require the context to be passed in on each invocation. Instead, the context is established when you declare the feature flag.
Learn more about identify
A downside of using the SDK of a specific provider is that it makes it hard to switch to a different feature flag provider at a later point. Often, the provider's SDK becomes deeply integrated into the codebase over time.
The Flags SDK does not lock you into a specific provider. You can switch to a different provider by changing the definition of the feature flag. Switching providers is possible without changing where your feature flag is used.
The Flags SDK further contains an adapter pattern for this, which streamlines swapping providers.
Learn more about adapters