search

open-feature / spec

OpenFeature specification
https://openfeature.dev
Apache License 2.0
588 stars 35 forks source link

Multi Provider for OpenFeature #255

Open beeme1mr opened 2 months ago

beeme1mr commented 2 months ago

Overview

A multi provider acts as a unified abstraction layer, allowing developers to consolidate feature flag access through a single API. With a multi provider, developers can simultaneously support multiple providers, making it easier to migrate between them.

Requirements

### Tasks
- [ ] Define a name for the provider
- [ ] Document supported scenarios
- [ ] Create a sequence diagram describing the data flow of each scenario
- [ ] Implement the provider in multiple languages
- [ ] Document the requirements in the OpenFeature spec

Resources

Ideas

Pseudo code

OpenFeature.setProvider(
  new MetaProvider([
    new EnvVarProvider(),
    new DbProvider(),
    new NextGenProvider3000(),
  ])
)

Questions

Prior art

federicobond commented 2 months ago

One key detail that came up when I did a PoC of an aggregated provider like this is how to handle provider events (and lifecycle) outside of the main provider registry (using SDK-specific, not spec terminology here).

Providers can emit events spontaneously and these events will have to be routed through the meta provider before bubbling to the main SDK event handling code, as they would belong to an unregistered provider.

It's hard to avoid this because events are necessary to properly keep track of each provider status. SDKs might want to provide a standard implementation of such a provider lifecycle manager to ease the writing of aggregated providers and ensure consistency in handling events and status changes.

weyert commented 2 months ago

I like the idea of this provider but I am not super excited about the name of it. It's pretty meta (🤭)

For OpenTelemetry I have a similar thing for the exporters so it sends it both to otel-collector and Stackdriver and I could this the CompositeExporter.

Maybe some naming similar to that might be more clarifying?

maxveldink commented 2 months ago

Meta was a better name than multiple_source from my original implementation 😂 But, I do like the idea of composite and am open to other name ideas too.

The only strategy currently implemented in the Ruby contrib is first_match, which short-circuits when we get a successful resolution details match from a provider. The other one I'm immediately thinking about is one that evaluates all providers (so logging hooks can be executed) for a flag and allows specifying a precedence order. Those are the two most important use cases I can foresee.

markphelps commented 2 months ago

👋🏻 just throwing my two cents re: naming. I also like CompositeProvider

Another idea: MultiProvider like io.MultiReader in Go

federicobond commented 1 month ago

I think we need to dig into the specific scenarios or use cases before we decide on naming because we can very well be talking about different provider implementations altogether.

For example, a CompareProvider (a provider that registers differences between the evaluation results of two different providers may be orthogonal to (and composable with) a StackProvider (a provider that returns the first match from a stack of providers.

lukas-reining commented 1 month ago

I think we need to dig into the specific scenarios or use cases before we decide on naming because we can very well be talking about different provider implementations altogether.

I am with you @federicobond. Having this would maybe make it more clear and also delimit it from other not "in-scope" use cases.