Alex

@a13xa5.bsky.social

13 Followers 5 Following

Learning & sharing OpenFeature knowledge 🏴 Find more on openfeature.dev

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'
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.
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.
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.
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.
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.
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).
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.
The TypeScript code snippet shows how one can create their own provider by implementing the Provider interface from the OpenFeature SDK.
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);
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.