Feature flags let teams release software while keeping new behavior switched off until it is ready. OpenFeature provides a consistent API for consuming and evaluating those flags without tying application code to one provider. The platform team can choose where flags are stored and how they are managed. section 7.3.4 section 7.5
A Go service can use the OpenFeature Go SDK to fetch flags from flagd. In one setup, flagd watches a Kubernetes ConfigMap containing the flag definitions. The service uses the SDK rather than implementing flag storage and evaluation itself; changing providers need not change its application code. section 7.3.4
Control event publishing by service
The Conference application defines an `eventsEnabled` flag with `all`, `decisions-only`, and `none` variants. Each variant gives a Boolean value for the agenda, notifications, and call-for-proposals services; `all` is the default. A service evaluates the flag with `s.FeatureClient.ObjectValue(ctx, "eventsEnabled", EventsEnabled{}, openfeature.EvaluationContext{})`. Changing the flag can alter a running application's behavior without restarting its components. section 7.3.5 section 7.5
Listing 7.7 Feature flag definitions, including variants
"eventsEnabled": {
"state": "ENABLED",
"variants": {
"all": {
"agenda-service": true,
"notifications-service": true,
"c4p-service": true
},
"decisions-only": {
"agenda-service": false,
"notifications-service": false,
"c4p-service": true
},
"none": {
"agenda-service": false,
"notifications-service": false,
"c4p-service": false
}
},
"defaultVariant": "all"
Inspect the complete `eventsEnabled` definition to see how one flag supplies different values to three services. section 7.3.5
