OpenFeature appears to be the feature flagging industry's attempt at some standardization. It claims "unified API and SDK", from what I can tell, that API is library API within the SDK, and not any particular network protocol.
The spec and API are deceptively simple, "just" make a library call to get a value, and there will always be one because it will fall back to the default value, and go on your merry way.
1package main
2
3import (
4 "context"
5
6 fromenv "github.com/open-feature/go-sdk-contrib/providers/from-env/pkg"
7 "github.com/open-feature/go-sdk/pkg/openfeature"
8)
9
10const (
11 FlagA = "flag_a"
12 FlagADefault = "a default value"
13)
14
15func main() {
16 var ffProvider fromenv.FromEnvProvider
17 openfeature.SetProvider(&ffProvider)
18
19 ffClient := openfeature.NewClient("client-1")
20
21 // while doing something
22 f, err := ffClient.StringValue(context.Background(), FlagA, FlagADefault, openfeature.NewEvaluationContext("", nil))
23 if err != nil {
24 // log it?
25 // will always return a value, even if default
26 }
27 // do something with f
28}
While there is a spec it only seems to specify the API and not the expected behaviour of the providers. For example, you pass each evaluation an EvaluationContext, but I didn't find any clear indication of how the values passed in would be used, and this (imo) limits the usefulness, because you're never sure what you're getting out of the evaluation, and you have to code defensively against it.
flagd looks to be their attempt at a server / network protocol for flags that can actually change values. It takes in config from different sources (files, k8s CRD, etc), and exposes them over multiple protocols using buf's connect-go library with a gRPC based API. The api spec seems to only be available via buf.build.
The file based configuration exposes more people to the horrors of JsonLogic. Have you ever wanted to program in an AST, in JSON? Well now you can.