Alex
@a13xa5.bsky.social
Learning & sharing OpenFeature knowledge 🏴
Find more on openfeature.dev
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
#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
GitHub - open-feature/protocol: OpenFeature Remote Evaluation Protocol
OpenFeature Remote Evaluation Protocol. Contribute to open-feature/protocol development by creating an account on GitHub.
github.com
March 24, 2025 at 9:16 PM
*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
#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!
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!
March 22, 2025 at 7:58 PM
*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!
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
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
March 20, 2025 at 9:38 AM
*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
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 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
March 15, 2025 at 10:24 AM
*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 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
*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.
#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.
March 10, 2025 at 8:19 AM
*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.
#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.
*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.
#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.
March 7, 2025 at 1:42 PM
*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:
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:
March 5, 2025 at 7:53 AM
*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:
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:
*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).
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).
March 3, 2025 at 7:45 AM
*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).
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).
*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.
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.
February 28, 2025 at 8:20 AM
*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.
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.
Reposted by Alex
OpenFeature Summit talk schedule lookin' 🔥🔥🔥
See us at the summit, as well as at KubeCon EU!
See us at the summit, as well as at KubeCon EU!
OpenFeature at KubeCon EU '25 | OpenFeature
OpenFeature at KubeCon EU '25
openfeature.dev
February 27, 2025 at 2:04 PM
OpenFeature Summit talk schedule lookin' 🔥🔥🔥
See us at the summit, as well as at KubeCon EU!
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.
#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.
February 27, 2025 at 7:13 AM
*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.
#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.
*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 #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.
February 26, 2025 at 7:25 AM
*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 #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.
*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.
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.
February 21, 2025 at 7:42 AM
*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.
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.
*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.
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.
February 20, 2025 at 7:47 AM
*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.
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.
*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.
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.
February 19, 2025 at 7:53 AM
*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.
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.
*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.
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.
February 18, 2025 at 7:18 AM
*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.
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.
*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.
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.
February 17, 2025 at 7:41 AM
*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.
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.