MultipleSourceProvider optional utility for Client SDKs

[maxveldink]

One meta-provider we've had to implement is a MultipleSourceProvider, which is initialized with a collection of providers used to search for a flag key, ordered by the collection. This is similar to using domains to bind different providers to different clients but slightly different as we're using it to consolidate the four different feature flag storage mechanisms we used in our monolith.

I'm wondering if others have run into this, and this is a common use case, especially as projects are onboard to OpenFeature. Would it be a helpful utility to call out in Appendix A as an optional utility that SDKs could implement?

[maxveldink]

Brought this topic up in the Community meeting today. I had a few takeaways:

• This topic has often come up under different names (Meta, Super, etc.). There have always been slight variations in what this does and its function, but it is relatively common, especially for migration to OpenFeature or a new provider.
• This is an excellent candidate to share as a blog post around using the provider interface to achieve this idea for the various use cases. I am going to take a stab at that.
• Language-specific implementations are good candidates for the contrib repos.
• The concept of "strategy" is important to dictate what should be done if multiple providers match a given flag key.

[federicobond]

A related concept I have been exploring is that of the OverrideProvider (a.k.a. ChainedProvider): a provider that delegates to another provider except for certain flag keys which are resolved by the OverrideProvider itself.

This would be helpful for testing, when you want to set a flag value for a given test case but keep the rest of the flags the same.
Think of the OverrideProvider as a MultipleSourceProvider composed of an InMemoryProvider and the original provider.

[maxveldink]

Interesting! I hadn't considered that, but it makes a lot of sense.