[OFREP] Flipt-agnostic flag evaluation in combination with environments/namespacing

[DerkSchooltink]

One of the powerful features of Flipt is separation by environment and/or namespace. Evaluation a flag across those dimensions is trivial using Flipt SDKs but is not really possible if you use OFREP.

The problem arises from the fact that environments and namespaces are not concepts in the openfeature specification. Flags in openfeature specification can just be evaluated with provided context, which is practically a map with key/values that can be matched against. This context can be leveraged to create the illusion of environments and namespaces.

In order to integrate OFREP evaluation on Flipt, I would argue it makes sense to define constants for environment and namespace context keys that are not Flipt-specific, in order to avoid implementation-detail specific properties to leak through the OFREP abstraction on the client side.

To be explicit, this is how I would envision such an integration from the client side:

import (
	"github.com/open-feature/go-sdk-contrib/providers/ofrep"
	"github.com/open-feature/go-sdk/openfeature"
)

provider := ofrep.NewProvider("https://my.flipt.server.com")
openfeature.SetNamedProvider("demo-app", provider)
client := openfeature.NewClient("demo-app")

output := client.String(context.TODO(), "<flag>", "<default>", openfeature.NewTargetlessEvaluationContext(map[string]any{
	"environment": "<env>",
	"namespace":   "<namespace>",
}))

Flipt should be able to interpret environment and namespace evaluation context, and match it to Flipt environment and namespace to fetch the flag provided.

This will be a breaking change for people who are using these keys to match with existing rules, but in my opinion a better way of integrating OFREP with Flipt-specific concepts.

I am available for opening up a pull request if this gets support. :)

[erka]

Hey @DerkSchooltink

Thank you for raising this up. I believe this was discussed few times with Open Feature team and they recommended to use http headers for such information. So it would be better to use ofrep.WithHeaderProvider option during the ofrep provider creation for this.

Flipt uses X-Flipt-Environment http header for evaluation API internally. X-Flipt-Namespace could be another option for ofrep integration.

We are happy to see your contributions to the project. You are welcome!

[DerkSchooltink]

Interesting. That should work, but doesn't remove the problem of making the OFREP implementation on the client side Flipt-agnostic.

Purely pragmatical, this doesn't matter and I can easily set up my local stack such that all clients are required to provide these headers, but from a conceptual standpoint it would be nice to leave clients unaware that Flipt is my OFREP server 😁

[erka]

It depends on your use case. But let's say there is some configuration management which provides the ofrep url and extra headers for the app service(like environment variables, .env file or any provider like k8s secrets, vault, aws secretsmanager...). Your client code may look like

	// use some static configuration to initialize this
	providerURI := "https://my.flipt.server.com"
	providerExtraHeaders := map[string]string{
         // ... values here loaded from static configuration
    }

	// init ofrep provider
	ops := make([]ofrep.Option, 0)
	for k, v := range providerExtraHeaders {
		ops = append(ops, ofrep.WithHeaderProvider(func() (string, string) {
			return k, v
		}),
		)
	}

	provider := ofrep.NewProvider(providerURI, ops...)
	openfeature.SetNamedProviderAndWait("demo-app", provider)

	// use openfeature
	client := openfeature.NewClient("demo-app")

	output := client.String(context.TODO(), "<flag>", "<default>", 
openfeature.NewTargetlessEvaluationContext(map[string]any{}))

Your evaluation context contains only business related properties. It shouldn't include extra info in each api call which is easy to miss sometimes.