@a13xa5.bsky.social
Learning & sharing OpenFeature knowledge 🏴 Find more on openfeature.dev
*8d -> #KubeCon & a bit of #OpenFeature a day #16*
#OFREP is short for OpenFeature #Remote #Evaluation #Protocol. It is a protocol specification for the #communication between #providers and feature flag management systems that support it.
Find it on github.com/open-feature/protocol
*10d -> #KubeCon & a bit of #OpenFeature a day #15*
With the specification of the #TrackingAPI, we can tie application #metrics & the feature flag system together; without requiring a vendor to support flag #analytics or having 2 separate systems; we can send all data to the same analytics backend!
*12d -> #KubeCon & a bit of #OpenFeature a day #14*
TIL: using the #OpenTelemetry #protocol ( #OTLP ) applications can be instrumented to send #telemetry data to analytics backends. This even works when running the app #locally!
Pro tip: set the env var 'OTEL_LOG_LEVEL=debug' for development
*17d -> #KubeCon & a bit of #OpenFeature a day #13*
The OF #project consists of >40 #repositories. Most essential to the standard are:
/spec: contains the standardization
/*-sdk repos: language-specific #SDK implementations of the spec
/*-sdk-contrib: lang-specific provider & hook #implementations
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'
*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.
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.
*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.
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.
*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:
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.
*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).
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.
*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.
OpenFeature Summit talk schedule lookin' 🔥🔥🔥
See us at the summit, as well as at KubeCon EU!
*33 days until #KubeCon & a bit of #OpenFeature a day Nr. 7*
#Experimentation is the term for testing the #impact of a new feature. Certain #metrics of the new feature can be #tracked to, e.g., check if users even like to use the new feature. #Tracking enables product decisions based on #data.
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.
*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 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).
*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 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.
*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 shows how one can create their own provider by implementing the Provider interface from the OpenFeature SDK.
*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 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);
*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 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.
*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.
