Playground
OpenFeature SDK demos and experimentation
Install / Use
/learn @open-feature/PlaygroundREADME
Welcome to the OpenFeature playground
The OpenFeature playground is a great place to familiarize yourself with the core concepts and features available in OpenFeature. If you're brand new to feature flagging, consider reviewing the What are feature flags? section in our documentation before running the demo.
<!-- Can be updated automatically by running `npm run markdown-toc` > <!-- toc -->- Pre-requisites
- How to run the demo
- What's in the demo?
- Available providers
- Experimenting beyond the demo
- Troubleshooting
Pre-requisites
In order to run the demo, you'll need the following tools available on your system.
How to run the demo
-
Clone the repo
git clone https://github.com/open-feature/playground.git -
Navigate to the playground folder
cd playground -
Copy
.env.exampleto.envcp .env.example .env -
Optionally, add feature flag vendors to the
.env. See below for more information. -
Start the demo
docker compose up -
Open your favorite browser and navigate to http://localhost:30000/
What's in the demo?
The demo consists of three different scenarios where feature flags are used. They help the fictional company Fib3r safely test and release new features. Two of the flags are client-side flags, which are evaluated in the web browser. One is a server-side flag, which is evaluated on the web server.
Rebranding
As we all know, naming is hard! In this scenario, the team at Fib3r is in the process of rebranding from FaaS to Fib3r. This may seem like a situation where a feature flag is unnecessary. However, many times, a rebranding needs to correspond with a press release or blog post. Of course, you could time a deployment moments before the announcement, but that's potentially risky and may require coordination across multiple teams. Using a feature flag would allow you to deploy when it's convenient, test in production by enabling the feature for a subset of users, and then enable it instantly for everyone.
For the rebranding effort, we're only interested in being able to toggle the new welcome message on and off. A boolean value is exactly what we need! That can be accomplished in OpenFeature like this.
Experimenting with color
The team at Fib3r has a hypothesis. They feel that the reason Fib3r hasn't achieved unicorn status is that the current color of the landing page is responsible for high bounce rates. This is a great opportunity to use feature flags for experimentation. With feature flags, it's possible to measure the impact a change has on the metrics that are important to your business.
Diving into the code, you may notice that an after hook has been defined. Hooks are a powerful feature that can be used to extend OpenFeature capabilities. In this case, the code expects a valid CSS hex color value. However, the person configuring the feature flag in a remote feature flag management tool may not be aware of this requirement. That's where a validation hook could be used to ensure only valid CSS values are returned. In this hook, the evaluated value is tested against a regular expression. If it doesn't match, a warning message is logged, and the hook throws an error. OpenFeature will catch the error and return the default value.
Test in production
Fib3r is on a mission to help the world calculate the nth digit of Fibonacci more efficiently. According to a Stack Overflow article the team recently found, it's possible to use Binet's Formula to calculate Fibonacci more efficiently. While the initial tests look promising, changing the underlying algorithm Fib3r has used for years is risky. The team decided that it would be safer put the new feature behind a context-dependant feature flag so that only employees could use it initially. If the test goes well, the feature could be slowly rolled out to everyone or quickly reverted if an issue is discovered.
Let's see how this could be done using OpenFeature. Here is where the Fib3r team adds a feature flag that returns the name of the algorithm to run. Looking closely at the getStringValue method, you'll notice evaluation context is not being defined. Evaluation context is commonly used in feature flagging to determine the flag value dynamically. For example, the Fib3r team may want to test the binet algorithm on employees only. This can be done by setting the user's email address as evaluation context and defining a rule that returns binet only when the email address ends with @faas.com. Simple enough, but remember that the evaluation context wasn't explicitly set during the flag evaluation linked above. That's because OpenFeature allows developers to set evaluation context at various points in their application. In this case, evaluation context is set on each transaction and automatically used during flag evaluation.
Available providers
The following providers can be used in the demo. Locate the provider you're interested in using to learn more.
Environment Variable
The environment variable provider is a simple demo showing how environment variables could be used to make flag evaluations. Its purpose is to show how a basic provider could be implemented.
To get started, follow the instructions in the How to run the demo section. Once in the demo app, select env from the dropdown located at the bottom-right of the screen. To change a flag value, open the .env file in your favorite text editor. Update the flag values based on the options defined as comments above the flag key. When you're ready, save the file and restart the demo.
Using environment variables like this can be a good way to get started with feature flagging. However, the approach only supports basic use cases and is quite cumbersome.
flagd
flagd is an OpenFeature compliant flag evaluation daemon. Following the Unix philosophy, it provides one component of a full feature flagging solution: a service for storing and evaluating flags. It supports the ability to define flag configurations in various locations, including a local file, an HTTP service, or in the case you're using Kubernetes, directly from the Kubernetes API.
In this demo, FlagD starts automatically as part of the Docker Compose file. It's configured to watch a local file /config/flagd/flags.json for flag configurations. Feel free to modify this file and see how it affects the demo. Valid configuration changes should be reflected almost immediately.
A FlagD configuration is represented as a JSON object. Feature flag configurations can be found under flags, and each item within flags represents a flag key (the unique identifier for a flag) and its corresponding configuration.
Valid flag configuration options include:
State
state is required property. Validate states are "ENABLED" or "DISABLED". When the state is set to "DISABLED", FlagD will behave like the flag doesn't exist.
Example:
"state": "ENABLED"
Variants
variants is a required property. It is an object containing the possible variations supported by the flag. All the object's values must be the same type (e.g. boolean, numbers, string, JSON). The type used as the variant value will directly affect how the flag is accessed in OpenFeature. For example, to use a flag configured with boolean values, the getBooleanValue or getBooleanDetails methods should be used. If another method, such as getStringValue is called, a type mismatch occurs and the default value is returned.
Example:
"variants": {
"red": "c05543",
"green": "2f5230",
"blue": "0d507b"
}
``
Related Skills
node-connect
342.5kDiagnose OpenClaw node connection and pairing failures for Android, iOS, and macOS companion apps
frontend-design
85.3kCreate distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
openai-whisper-api
342.5kTranscribe audio via OpenAI Audio Transcriptions API (Whisper).
qqbot-media
342.5kQQBot 富媒体收发能力。使用 <qqmedia> 标签,系统根据文件扩展名自动识别类型(图片/语音/视频/文件)。
