Alex
LightNews LightNews
a13xa5.bsky.social
Alex
@a13xa5.bsky.social
13 followers 5 following 16 posts
Learning & sharing OpenFeature knowledge 🏴

Find more on openfeature.dev
Posts Replies Media Videos
a13xa5.bsky.social
*22d -> #KubeCon & a bit of #OpenFeature a day #12*

#EvaluationDetails are a flag evaluation's returned data structure. It contains data like the #flagKey, #errorCode, #variant, #reason & #metadata, such as #contextId or #flagSetId. These can be mapped to #OpenTelemetry #log #record conventions.
The table in the image shows the mapping between OpenTelemetry feature flag log record conventions and OpenFeature evaluation details fields. Eg. log record attribute 'feature_flag.key' can be mapped to 'flag key'
March 10, 2025 at 8:19 AM
a13xa5.bsky.social
*25d -> #KubeCon & a bit of #OpenFeature a day #11*

#Events are state changes of the #provider: ready, configuration changed, error, stale
#Event #handlers can be implemented to react to those. Eg. maybe we want to wait until the provider is 'ready' before evaluating feature flags for rendering UI.
In the TypeScript code snippet, one can see how an event handler can be added to the OpenFeature client. It shows 2 examples for event type ready and configuration changed.
March 7, 2025 at 1:42 PM
a13xa5.bsky.social
*27d -> #KubeCon & a bit of #OpenFeature a day #10*

Looking at actual #code examples makes it obvious what #tracking calls are used for. Calling the #track function via the #OF #client and passing #TrackingEventDetails a numeric value and other optional data can be sent to the backend:
The code snippet shows how the OpenFeature client's track function is called passing a tracking event name and TrackingEventDetails, which consist of a numeric value here. In the example, the 'clicked-checkout' event is tracked with a value of 99.77. For server-side applications, the evaluation context parameter can be optionally passed to analyze tracking events in the context of the current user session.
March 5, 2025 at 7:53 AM
a13xa5.bsky.social
*29d -> #KubeCon & a bit of #OpenFeature a day #9*

To support tracking the OpenFeature #provider needs to implement the #Tracking interface, which contains a single function called track. This function performs #side-effects to record the tracking #event (e.g. store a specific metric).
This java code snippet shows how a provider can be implemented to support tracking. It implements the Tracking interface by implementing a track function that returns void. As parameters an event name, an evaluation context and tracking event details can be passed.
March 3, 2025 at 7:45 AM
a13xa5.bsky.social
*32d -> #KubeCon & a bit of #OpenFeature a day #8*

How does #tracking work?
Calling a #track function stores certain #metrics for a user session (e.g. total purchase amount). #Hooks can be used to store info about #flag #evaluations. Combined, one can see, e.g., how a new feature impacts purchases.
The sequence diagram shows the function calls that are necessary to implement tracking. A tracking hook sends data about flag evaluations coming from the Evaluation API to the Analytics Platform. A separate track call from the Evaluation API to the Analytics Platform stores data about the user session.
February 28, 2025 at 8:20 AM
a13xa5.bsky.social
*34 days until #KubeCon & a bit of #OpenFeature a day Nr. 6*

The #Flag #Evaluation #Life-Cycle has 4 stages: before, after, error and finally.
In each stage, so-called #Hooks can be implemented to perform certain activities such as changing a context variable, #logging or cleaning up resources.
The image shows all 4 stages of the flag evaluation life cycle as OpenFeature specifies it. Before and finally are always called. The after hook is called in case of a successful flag evaluation and error else. Finally comes at the end.
February 26, 2025 at 7:25 AM
a13xa5.bsky.social
*39 days until #KubeCon & a bit of #OpenFeature a day Nr. 5*

There are #client-side and #server-side OpenFeature #SDKs. The main difference lies in the usage of the #evaluation #context which changes with every server request but usually stays the same for a single user on the client-side.
The TypeScript code snippet shows how evaluation context can be used with server-side OpenFeature SDKs. In contrast to client-side SDKs, the context needs to be passed to every flag evaluation request. However, if contexts are valid globally, they can be set the same way as in client-side SDKs (see also previous post).
February 21, 2025 at 7:42 AM
a13xa5.bsky.social
*40 days until #KubeCon & a bit of #OpenFeature a day Nr. 4*

What is an OF evaluation context?
A context is a variable that can be used for #dynamic flag #evaluations. A feature can be toggled for specific users by using e.g. the email address as a context variable.
The TypeScript code snippet in the picture shows how context can be set using a client-side OpenFeature SDK. In this example, the context variable myUserData is set to a static value. The context is used for all feature flag evaluations automatically and only needs to be set once.
February 20, 2025 at 7:47 AM
a13xa5.bsky.social
*41 days until KubeCon & a bit of OpenFeature a day Nr. 3*

What is an OpenFeature Provider?
A provider is the adapter between the Evaluation API and the feature flag management system. In other words: if a flag value is requested via Eval API the provider knows where to find the flag configuration.
The TypeScript code snippet shows how one can create their own provider by implementing the Provider interface from the OpenFeature SDK.
February 19, 2025 at 7:53 AM
a13xa5.bsky.social
*42 days until KubeCon & a bit of OpenFeature a day Nr. 2*

What is the Evaluation API?
It is part of the OpenFeature SDK and, as the name suggests, a standardized API for evaluating feature flags. The resulting value can be used in code to toggle specific features on and off remotely.
The picture shows a line of Java code that fetches a boolean feature flag value with the name "boolFlag" and default value "false" using the OpenFeature Evaluation API. It assigns the resulting value to a Boolean variable that can be used to impact control flow to remotely activate or deactivate certain functionality of the application. The call is: Boolean boolValue = client.getBooleanValue("boolFlag", false);
February 18, 2025 at 7:18 AM
a13xa5.bsky.social
*43 days until KubeCon & a bit of OpenFeature a day Nr. 1*

Let's tackle the most obvious question to start this with:

What is OpenFeature?
A standardization of feature flagging.
It's an open-source project, part of the CNCF landscape & and standardizes the look and feel of feature flags.
The OpenFeature Architecture diagram shows how OpenFeature is used for feature flagging within an app. The app in the picture owns a feature-flagging client that is used for flag evaluations. To show case OpenFeature the client in the image consists of the OpenFeature SDK and an OpenFeature provider. The SDK provides the flag evaluation API for the flag requests from the app. The provider is connected to an imaginary Flags-R-us service hosted somewhere else that stores the flag configuration.
February 17, 2025 at 7:41 AM