feat: draft of pluggable flagd evaluators powered by OpenFeature providers

[tcarrio]

This PR

The end goal is to allow flagd to be powered by OpenFeature providers. There are multiple approaches to this:

1. Plugin architecture using the Go standard library plugin package
2. Bundling evaluators with flagd builds

Plugins

• proposes a new provider plugin architecture that allows flagd to be powered by dynamically loadable evaluators (IEvaluator)
• flagd plugin adapters would exist that automatically support OpenFeature Providers and Clients

Bundling

TODO

Related Issues

https://github.com/open-feature/flagd/issues/210

Notes

Draft status. Looking for feedback.

Follow-up Tasks

Flesh out the implementation section and any additional clarification or elaboration of the OFEP.

How to test

[tcarrio]

A TODO followup here: IEvaluator defines a method for getting all flags. This is explicitly not included in the OpenFeature spec from whence I last checked. So, this would be one potential stopper to this approach as being able to "drop-in" OpenFeature providers.

[beeme1mr]

@tcarrio, is this the plugin system you're talking about? https://pkg.go.dev/plugin

[tcarrio]

Yeah that one is part of the standard library now. I can add some more info to the ofep around this in a couple hours.

[tcarrio]

@beeme1mr an example for how the plugin architecture could work is included in the example section of the plugin proposal now.

[tcarrio]

IEvaluator defines a method for getting all flags [...] is explicitly not included in the OpenFeature spec

Additionally this could follow the HTTP status code logic of 501 Not Implemented. But whatever that is for raw gRPC, while gRPC Web would just work.

[gagantrivedi]

@tcarrio @beeme1mr Once everyone agrees that the proposal has progressed to that point, I would be love to create a proof of concept using the Flagsmith Go provider as a plugin.

[InTheCloudDan]

I would like to understand the additional value we are looking to gain from this implementation along with the tradeoffs.

From a review it appears it will make it easier to swap providers which can be a positive. On the other side there is additional implementation risk. And there may be a list of these tradeoffs which I'd like us to catalog before committing.

How the LaunchDarkly SDK works today is all locally in memory. If we take a kubernetes example and instead of configuring it as a sidecar, an end user sets it up as a daemon pod, they will end up risking significantly worse performance that is "hidden away" from the end users.

If we go this route and flagd stays in OpenFeature I am also concerned it's setting the precedent that this is the expected setup. During our community calls there were parallels with OpenTelemetry Collectors, but flagd is the opposite of that. Collectors(from my understanding) are only receiving data from applications, whereas flagd will be directly in the code path of evaluating functions.

I am for exploring the concept but do not think external providers should be a foregone conclusion.

[tcarrio]

To be clear @InTheCloudDan , I do not think that this impacts general OpenFeature clients, but extends the flagd support to serve using an OpenFeature client.

There is still unquestionable value in the OpenFeature client directly being used. The flagd operator is, in my opinion, a fairly advanced use case, but one that is well supported by OpenFeature.

And of course, you can always update your OpenFeature clients to use a LaunchDarkly provider instead of flagd.

Anything built to use the OpenFeature client is inherently platform agnostic, so the only technical reason you need to use flagd as a proxy would be because there is no support for your language of choice (e.g. there is a Go provider but not a Rust provider for vendor X). Otherwise it's an architectural decision.

I think the point is important though that the documentation is clear about the architecture and ramifications.

[tcarrio]

Do you think the sidecar architecture would be preferred in some cases over the more traditional in-process evaluation?

Using flagd to provide immediate support for a vast majority of providers across many languages. For example, if you have to write code in Python, TypeScript, Rust, and PHP 👋 then this would be very difficult to start with OpenFeature. For less popular languages, there may not even be an official vendor for it (Rust).

The provider that gets immediate support in OpenFeature generally is flagd. With that in mind, we could utilize flagd sidecar or node-local instances to support any vendor with a Go implementation. Now Rust services can launch with sidecars and support for any vendor.

This is also a way to provide support for less mature ecosystems (I've written the only 3 providers for PHP, Rust is early stages, Python is still not spec compliant).

[tcarrio]

My only concern was the fact that get all flags would be broken, but if the purpose is to support an OpenFeature client then that will never be called anyway. The set of client APIs is a subset of the flagd API.

[toddbaert]

@InTheCloudDan ,in addition to @tcarrio 's valid points, I think there's 2 other interesting use-cases:

• Some vendors have proxy services that run within an organization's infrastructure and serve as a point to do caching and control outbound connections. flagd could constitute a basis for similar functionality, particularly for vendors that don't have comparable proxy solutions.
• Maintaining the provider in flagd allows for a central point for feature flag source-of-truth configuration. An administrator could transparently manage switching or aggregating flags from various backends without impacting or requiring changes from client workloads. I think this is a somewhat "academic" point, I'm not sure it would be practically useful, but worth mentioning.

[tcarrio]

I started a PoC for this last night, it's not complete or tested it's just the idea right now.

See https://github.com/open-feature/flagd/pull/553 for more info.

[github-actions[bot]]

This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in next 60 days.

[tcarrio]

I'm going to close this one out in favor of #67, which should hopefully define a standard wire protocol that might be useful to support these cases.