Use IConfiguration to setup Unleash

[thompson-tomo]

Summary of pain point
I wish to have the settings for unleash to be configured just like my other services which use the builtin configuration Interface.

The solution I'd like
To have unleash in the scenario where no settings is provided to use the values in IConfiguration. Alternatively a custom section can be passed in.

Describe alternatives you've considered
Make local extension methodd

Additional context
Wanting to bring a consistent dotnet experience to unleash

[thomasheartman]

Hey, @thompson-tomo! Thanks for the feature request 😄 This sounds like a sensible feature, but we unfortunately do not have the capacity to implement it ourselves at the moment. Would you be willing to implement it yourself and send us a PR that we could have a look at? This goes for your other two requests too (#184, #185).

If not, I'd be happy to capture your ideas in our idea board and we'll revisit them for our next quarterly planning session.

[thompson-tomo]

@thomasheartm sure I have no problem working on the issues I am raising and submitting them via PR'S. Based on the scope and increased flexibility I think one of the first issues to tackle should be #192 as it would simplify this issue & others.

[thomasheartman]

Hey, @thompson-tomo. Thanks for getting back to me (and also for the new feature requests).

We've had a look through them on our end, and we're not sure we want to tackle all of them. Some of them sound relevant however, so we'll take a bit of time and respond to each on of them separately, if you don't mind. Please hold tight in the meantime.

But with all the feature requests you've opened, could you outline for me the end goal? There appears to be a red thread binding them together; what is your use case for all these things?

[thompson-tomo]

The end goal which I am looking for is flexibility in use cases:

• Feature flags have the flexibility to be sourced from unleash or static files which is injected into ICONFIGURATION in either Unleash Or Microsoft Schema
• the processing of the strategies is triggered by Microsoft Feature flag SDK including having feature flag's in *.cshtml. The strategies processed could be Unleash strategies or Microsoft strategies.
• All logging is done using the suggested approach from Microsoft & removes deprecation warnings.
• usage of feature flags is consolidated alongside other application metrics ie performance and can be transported to the same analysis tools ie ELK
• An exporter is available to export the standard metrics to Unleash.

In my use case feature flags will be transported to distributed servers via Rabbitmq and cached locally Hence the ICONFIGURATION. The usage should be visible in ELK with the upload also occurring via Rabbitmq. Feature flags should easily control ui aspects.

Hope that provides further info.

I would suggest looking at the ELK libs as a sample of what I am thinking.

[daveleek]

Hello @thompson-tomo!

We were working on proper replies for individual issues, but I'll address your concerns here instead.

Feature flags have the flexibility to be sourced from unleash or static files which is injected into ICONFIGURATION in either Unleash Or Microsoft Schema

Unleash has support for a concept we call Bootstrapping. In short you can configure Unleash with one of two existing bootstrappers during startup, or write your own bootstrapper. The provided bootstrappers support loading from static file or URL

the processing of the strategies is triggered by Microsoft Feature flag SDK including having feature flag's in *.cshtml. The strategies processed could be Unleash strategies or Microsoft strategies.

The strategies we provide are available in the NuGet package as public classes and the SDK is open source, so you are free to configure these with anything you like but you will have to write some plumbing code yourself. And implementing a wrapper around the usage of Unleash is also a good idea.

All logging is done using the suggested approach from Microsoft & removes deprecation warnings.

Logging and serialization is on our radar to fix

• usage of feature flags is consolidated alongside other application metrics ie performance and can be transported to the same analysis tools ie ELK
• An exporter is available to export the standard metrics to Unleash.

All metrics are sent to Unleash through an implementation of IUnleashApiClient that is exposed as a setting on UnleashSettings class used when creating a new Unleash instance. There are admin API endpoints on the Unleash service from which metrics can be obtained, but there's also the option of implementing the IUnleashApiClient interface your end and forwarding the metrics from that. You would have to either implement a feature flag fetching mechanism there or proxy to an instance of the UnleashApiClient as well to implement that interface, but this could also be used to address your static file question. We're recording this idea however, so thank you, it could be useful to look at transporting metrics out from the Unleash service!

In short I think you should be able to achieve most of your goals here by implementing/configuring/connecting some of our interfaces/apis. We're looking at improving the host-setup parts of Unleash to cater to both .NET Framework and .NET Core environments, and we're also looking at improving logging/serialization.

Overall this SDK exists to serve users of the Unleash platform and we have quite a few of these SDKs. They all need to conform to the same spec/feature set with a few platform specific needs having to differ between them. So larger reorganizations, splitting out parts of it, and maintaining SDK level integrations are currently not a priority

[thompson-tomo]

Hi @daveleek

I am perfectly fine with the functionality being offered in a consistent across platforms but the big thing I like to see is consistency in the stack & simplicity in integrating a new library. At the same I also appreciate reducing maintenance effort across the board rather simply transferring the responsibility to others which in the end results in overall more effort. I know what I want to do could be done by building a lot of extensions but fear impact on performance & bloat caused by doing so.

I think the logical first step would be to facilitate the DI registration then move on to loading config from application Config. This would then enable devs to do the core functionality like they do with other libraries. Then work other aspects

This is part of the reason why I created small focused issues as othwise it wouldn't be managable. I lam happy to be contributing on this journey.

[daveleek]

Hello @thompson-tomo.

I've closed a few of the issues you posted as they don't align with what this SDK is trying to achieve.
This SDKs primary concern is to be an integration SDK for the Unleash eco system on the .NET platforms.
It is not intended as a standalone library.

The hosting/setup aspect of this library is something we're discussing improving, we are also looking at improving logging, and we're in the process of evaluating which framework versions we should support moving forwards.

[PhbsSmn]

I agree with @thompson-tomo , we had to do some custom effort to integrate this in our DI container eco system.
We went for this approach so that we could isolate the functionality provided by unleash.

Once we got to this point the entrypoint of our project was able to set context to unleash if needed, and then the application or infra layer was able by just requesting a context via an interface in the constructor unaware of using unleash. They just requested if a toggle was on or of via an interface.

In fact I think if you would make the toggles available as a custom configuration provider you would even be able to use it with the FeatureGate functionality in webapi controllers. But I guess this approach is surrounded by a niche on its own.