Multi Provider for OpenFeature

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

• https://cloud-native.slack.com/archives/C0344AANLA1/p1713969371600029
• Kickoff meeting:
  • https://dynatrace.zoom.us/rec/share/2_BnAhWfih9DOiDG6WHwDC3zY49oe5EpX6a_tJ1fxzS7cexsEEts4VH8BG_Scyhl.I_01yQKFixmdPEdg
  • password: N0EPq=Q6

Ideas

• Flag metadata could be used to understand what provider was used to resolve the flag value
• Debug logging could be offloaded to an optional hook
• Extend appendix-a to include a section on the meta provider
• Leverage the evaluation details returned by the provider.

Pseudo code

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

Questions

• Should the meta provider live in the SDK or the contribs repo?
• Can the meta provider support provider hooks?
• What strategies should be supported out of the box?
• How should we handle provider events?

Prior art

• https://github.com/open-feature/js-sdk-contrib/pull/613
• https://github.com/open-feature/ruby-sdk-contrib/pull/17

Start by reviewing appendix-a, the evaluation details section, and the prior-art pull requests in the issue. Clarify the provider name, supported scenarios, strategies, hooks, and event behavior before defining the sequence diagrams and implementation scope. Done means the requirements are documented in the OpenFeature spec and the provider is implemented in the required languages.