Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Async API for featuremanagement #85
HI, I've been trying out the feature management package, and one of the design aspects that feels a little strange is that the API is entirely synchronous.
This totally makes sense from the consuming point of view, and when you consider you're driving it from
The lack of an
I'm assuming you decided against an
This is the biggest debate right now with the Feature Management API. Currently the API is developed as a thin API surface over IConfiguration with the core scenario of enabling or disabling feature's based off whether they are configured true/false. Being synchronous allows feature management to be integrated into parts of frameworks that require synchronous code paths, and since IConfiguration is synchronous it all makes sense.
We recognize that this is a large limitation in feature filters because like you mentioned, calls to servers could not be made unless they are blocking and also pulling data into the current HTTP context or configuration might be excessive especially since it is possible that this feature data might not be used during a given request.
Introducing async would require a breaking change of the core API
At the moment we are evaluating whether we want to make this breaking change (it's basically the biggest one we could make).
Synchronous has some benefits
Asynchronous has some benefits as well that you mentioned
If we make the move to async, some functionality that is possible with the current code will be lost, including some of the plugin points exposed into ASP.NET Core.
Thanks for the input @jimmyca15 - totally understand the issues with going async here, and everything you've said makes sense. I definitely think you need to go all-in on sync or async, not support both - agree that would be confusing.
Regarding the functionality that would be lost, the main one I see is the
My initial thought was regarding storing feature flag values in the database:
That last point makes the sync API mostly workable I think, but it does feel a bit hacky - it feels like you're fighting the featuremanagement library. I'm really not sure what's best tbh!