Feature flags allow for application behaviour to be controlled at runtime. Their implementations can be as simple as a home-grown environment variable interface or be a more complex evaluation system using metadata to derive the flag values. Many vendors offer feature flag services, and at a high level, all are the same, you pass a request and receive the evaluated flag of a set data type and use this value to manipulate the runtime of an application; however, at a code level, all these implementations can vary massively. The below example demonstrates this, with an example taken from 3 different vendors for boolean evaluation.
Within an applications codebase, it is common for flag evaluations to take place frequently, with some flags being evaluated multiple times on both server and client-side; as a result of this and the ‘similar but different’ approaches vendors use in their requests, vendor lock-in is typical, with applications becoming tightly coupled to their flag vendors.
OpenFeature is an open standard for feature flag management, created to support a robust feature flag ecosystem using cloud-native technologies. OpenFeature reduces vendor lock-in by introducing a unified API to which all vendors can conform. Any vendor can create a provider, a language-specific implementation that is simply a ‘translation layer’ between the evaluation API and the flag management system. Developers can then set this provider OpenFeature global singleton, which will be used in all clients. This means that switching from one vendor to another can be as simple as changing a single line of code. Metadata for each request is passed as an Evaluation Context object, which can be passed arbitrary contextual data that can be used as a basis for dynamic evaluation. Static contextual data can also be set globally. This metadata object can contain anything, but the key-value pairs are commonly related to the current user's session.
Leveraging OpenFeature in your application can be as simple as adding a few lines of code, below is an example using a simple environment variable JSON evaluation provider, which can be found here. This provider uses a JSON evaluation for matching a flag variant to a provided evaluation context. Each flag variant contains a slice of conditions; if all conditions match, then the value of the flag is returned. Each variant is evaluated starting at index 0. Therefore the first matching variant is returned. Each variant also has a targeting key; when set, it must match the targeting key provided in the evaluation context for the variant to be returned.
Above is an example of a feature flag which can be set as a JSON string with the key AM_I_YELLOW in the environment variable; once it has been set, we can evaluate the flag using the go-sdk as follows:
Now, if we wanted to switch to an entirely new flag vendor, we would just need to import the vendor-specific provider and replace the value being passed to openfeature.SetProvider. One example of one of these providers is the flagD provider. FlagD is a cloud-native flag management solution built from the ground up to leverage OpenFeature, easily installed and managed in K8s with an operator. Read more here.
To conclude, the OpenFeature project strives to improve the software development lifecycle by standardising feature flagging for everyone through standardised interfaces and a clean abstraction layer.