Custom Feature Settings Providers

[christogav]

We really like what we're seeing here - great work for bringing something like this to the community!

We'd like to propose that some of the interfaces be made public so we can switch out their implementations to interface either with legacy (in-house) feature management solutions or external vendors (LaunchDarkly, split.io et al) to provide a consistent abstraction layer across multiple different backends.

We're happy to contribute code if you're accepting PR's too.

[jimmyca15]

Hey @christogav it's a good suggestion. We are still working on some features that may result in tweaks to the current API surface. Once we finalize all of those items we can shift toward exposing the internals to make the library more open as you have described.

[antmdvs]

Hi @jimmyca15 ,

Could we please get visibility into the WIP features or is everything captured by https://github.com/microsoft/FeatureManagement-Dotnet/issues/created_by/jimmyca15?

Also I'd like to get an idea of when this lib might be considered stable..?

Thanks!

[josephwoodward]

Likewise, very interested to know when this is considered stable so we can start using it. I'm also interested in using it with external vendors. @christogav Out of interest, what are the interfaces you'd like to see made public?

[jimmyca15]

@antmdvs @josephwoodward

We have a couple of breaking changes in the dev branch awaiting a release.

• Async feature filters
• Contextual feature management
  

Currently we don't expect any breaking changes after that and after the release of these features we plan to give it a little bit of time for final feedback then release a stable version. All changes on top of that will be additive.

[christogav]

@josephwoodward Looks like IFeatureSettingsProvider is the main one. There may be others but I haven't looked in detail.

[antmdvs]

Given the original inquiry:

We'd like to propose that some of the interfaces be made public so we can switch out their implementations...

It doesn't seem to me this should be necessary to integrate with FFaaS providers, given that:

Any .NET Core configuration provider is capable of acting as the back-bone for feature flags.

as stated in the README.

IOW, would it make more sense to create a custom .NET Core configuration provider for, say, LaunchDarkly or whichever?

[wekempf]

I've been spiking this, and the problem as I see it is two fold.

1. Configuration providers are generally meant to be pretty static in nature. You load all configuration at once. Yes, you can reload, and yes it is possible with a bunch of work to make it work fully dynamically (though GetChildKeys may make it difficult for some providers), but this is pretty non-trivial stuff for this to feel like an abstraction like MEDI and MEL are.

2. At the configuration level we're missing context to be able to use existing feature flag backends. For instance, with Launch Darkly you can't interrogate a flag without having a user. Some hacky "access global state" approach might work here, but that approach is ugly at best.

Configuration should be a provider, not the only provider, and the provider abstraction should include context hooks.

[jimmyca15]

This has been added in the latest release.