Good stuff - feature toggles are required for successful CI, for sure. We use percentage flags often for A/B testing, or slowly rolling out a new version of something we are monitoring, or "canary" features for a subset of users. So you'd have two routes for /weatherforecasts - one with the new version, one with the old, one would be disabled if the flag is true, the other disabled, etc. You can do cool stuff like that when you are decomposing a monolith using a strangler fig pattern for example. What I wish was easier, and you hinted at it here, was the ability to change the container for the services based on feature flags. Since you can't change the services collection after the app is built, you have to do corny stuff like the common service locator thing you showed.
Feature flags are great for products that can be deployed for multiple clients who may want some features or enabled or disabled based on their requirements
We use feature flags on our project. FF is great when you need to enable or disable functionality depending on requirements. For example, multicountry applications where for some of the country feature could be enabled and for others be disabled. Also, disabling some features helps to test functionality on the prod without any damage because it will be hidden from the user
I was tought wait a sec, that could be done with simply adding a flag by yourself in appsettings, not via package. Then things got advanced ;) Great video
Great stuff, I decided to opt to use an enum to define the constants rather than const strings for the feature names. Though it's still going to be suspectable to breakages should the name be refactored. Meh, it's on me in this project. It's something small I'm making for myself.
I think you didn't show the main reason behind this package which is making your web application extensible ... with external DLLs as a plugin. the things you showed in this video is achivable easily with IOptionMonitoring and IOptionSnapshot interfaces. I think this is just a plugin management library.
Thank you for insights on this topic. Can you maybe elaborate further on this by explaining what is the best way of releasing some features for specific users. Maybe you could make a video on this topic.
One of the main reasons I see for this is trunk based developement versus other branching strategies like gitflow etc... wondering what you're thoughts are on that.
Exact my thoughts on this. If you use git flow then its barely possible you'd need features functionality. Ofc there are exceptions like when you want to use it for A/B testing or release some features only for specific group of users. All other use cases like ability to enable/disable features on prod sounds for me kinda wrong. If anybody disagree with me would be interesting to read your points
Actually, I have the same thought. It would encompass this feature more in my development team, considering another branching strategy. Currently, we use GitFlow, but the team has grown so much that our Staging environment has become a bottleneck. Therefore, I have also considered that using Feature Management at the version level might help manage a more transparent branching strategy between staging and production environments. For example, using the Trunk-Based Development (TBD) strategy, working with a single version Feature Flag and i would call it Version Flag, and if you want to work at a lower level, i will add a new level to use a feature flag. I see great advantages with this approach, as it would help our Staging and Production environments focus on a specific version... So, it is also understandable that the team must be disciplined in keeping the code updated by cleaning up the legacy code.
Hey Nick thanks for the video. Actually, I have the thought to use this feature more in my development team, considering another branching strategy. Currently, we use GitFlow, but the team has grown so much that our Staging environment has become a bottleneck. Therefore, I have also considered that using Feature Management at the version level might help manage a more transparent branching strategy between staging and production environments. For example, using the Trunk-Based Development (TBD) strategy, working with a single version Feature Flag and i would call it Version Flag, and if you want to work at a lower level, i will add a new level to use a feature flag. I see great advantages with this approach, as it would help our Staging and Production environments focus on a specific version... So, it is also understandable that the team must be disciplined in keeping the code updated by cleaning up the legacy code. What you do think over this tought?
perhaps this could be a good way to release a new api version for endpoints. for the percentage setting, maybe a nice use case would be for a game of chance
yes you can, you have to implement IFeatureDefinitionProvider and then add it as Singleton, you can check their repo in custom feature provider section and learn more.
Nice overview, thanks! Is there any strategy on how to coordinate feature flags being enabled/disabled with frontend? I guess both BE and FE should manage feature flags at the same time in order not to be in the situation of enabled BE feature, which is not visible from FE, or, what is worse, disabled BE feature, getting called from FE.
I use this in my project. The main problem is when you get too many, code gets a nightmare! You need to keep it to a minimum. The other issue is that we have it in Azure feature management (one for each environment). How can we override those configs for local development?
I have used FeatureGate attribute for NET 6 and had an interesting issue: my controller actions where not called, but Controller constructor was being called. I had to use some of my dependencies as Lazy so they creation was not triggered when feature was disabled
Hi Nick, Is FeatureManagement supported in .Net framework 4.8? I am unable to create a DI through autofac for adding the package to my service. Any advice on this please?
Would this be a viable solution for limiting features based on software license? Although the features would have to be retrieved from a license key or some other source.
No, that is not authorisation necessarily, yes you have to give permission to the user to use that feature, but the main thing here with feature flagging is that with FF you can enable a feature to some portion of your users, by country, by age, by email range etc etc.
Is it perhaps possible to load the configuration based on some parameters the application can test at run time? I have a case for Feature management, but it's less about toggling them at runtime, and more restricting what's available based on whether the target database has been fully upgraded (i.e. all features are available), or not (unsupported features are disabled). If not, this library is cool, but it's not for me. EDIT I suppose I could conceivably do this using a custom FeatureFilter...
Yes, it is a little different than what was shown here but one way that I have used has been for asynchronous development. Different teams/services agree on a contract or condition and then it doesn't matter what order development happens, the consuming service can finish out their code first and have a feature flag that their dependency enables when ready. For your use case, as I understand it, the target database would be like that dependent service, so your DB upgrade process could enable a flag when complete that your application can then consume. Any production Feature Flag services - for example the cloud-based ones that Nick mentioned - will have both SDK and REST options for setting the feature flags rather than only reading them.
@@alfflasymphonyx Exept it's a little for than that. For example, we have a implementation of a `ISessionManager` that looks at the HTTP request headers to determine wether a feature should be on or not, this overrides whatever comes from configuration. And so you could have multiple of these `ISessionManager` polling multiple sources if you would so like. This can also include specific user/session information, ect.
I think this is meant to separate between the responsibility of the configuration and feature management but yes all of this can be achieved by IOptionMonitor
Nice, thanks for sharing, We use this FeatureFlags for functionalities on our API's, however never used for endpoints, maybe would be nice to show how the Swagger looks like when you have the entire endpoint behind the featureFlag, it might be tricky if the flag is off and you use the swagger json to configure Azure API Management for example.
Excellent video. Thanks Nick. Could you do a video on Custom fields? Say a small contacts table where one company wants to list whether the contact is a smoker, gender, availability, etc and another company wants to log passport information, Dob, etc?
This function is almost useless or at least very bad practice in fair amount business scenarios. 1. You should not allow anyone just go to production portal and configure something which dramatically change a production without easy to investigate trace. 2. You should not listen to so called on fly appsetting change, as if you do that, in quite a lot of cases, your site/product will need to restart. Then what will happen to the users connected to your site/product? Suddenly they will lost connection. 3. If you put this in appsetting, and your site runs multiple instances, you will need to manually go update all these sites. BAD 4. If you put this in some central place and your site listen to the change, suddenly all the sites/products listen to this will all restart and your sites are all down. Evil. There may be some usages for this, but in the industry I am in (finance and data), I can't see any suitable scenarios for my work. If you want to enable some feature, do a deployment or use some other technique, but not this feature management
The use of the appsettings is usefull most for development. In production, the use of something like Azure App Configuration let you manage this with auditing and security in mind. And it doesn't restart the app, but configures multiple path in the app.
We sometimes use this to toggle some feature for test/acc/prod, but do so with a pullrequest and an actual redeploy. I always wondered why we use this package when its basically just the options pattern without using the on-the-fly changes. I guess because it's called FeatureManagement? Agreed with most of your points, but I think the way @JeffryGonzalezHt seems to use it sounds like a decent way to about it as well though.
@@JohanBenschop Another team demonstrated this App Configuration service together with this feature function some months ago and it was rejected by the company I work in. The problem with App config Service is that unlike keyvault, the value needs to be readed in periodically. Then the DI will also need to handle the change. It didn't provide enough value or at least evidence to support paying for this App Configuration Service.
About TimePeriodFilter. Am I right it resets every time I redeploy the application? I can't imagine a use case for that, I probably do not want the timer to reset on every deploy.
Good stuff - feature toggles are required for successful CI, for sure. We use percentage flags often for A/B testing, or slowly rolling out a new version of something we are monitoring, or "canary" features for a subset of users. So you'd have two routes for /weatherforecasts - one with the new version, one with the old, one would be disabled if the flag is true, the other disabled, etc. You can do cool stuff like that when you are decomposing a monolith using a strangler fig pattern for example. What I wish was easier, and you hinted at it here, was the ability to change the container for the services based on feature flags. Since you can't change the services collection after the app is built, you have to do corny stuff like the common service locator thing you showed.
Feature flags are great for products that can be deployed for multiple clients who may want some features or enabled or disabled based on their requirements
We use feature flags on our project. FF is great when you need to enable or disable functionality depending on requirements. For example, multicountry applications where for some of the country feature could be enabled and for others be disabled. Also, disabling some features helps to test functionality on the prod without any damage because it will be hidden from the user
Percentage is perfect for use case of trolling
Thank you so much, have been doing this manually... Will start using this library
I was tought wait a sec, that could be done with simply adding a flag by yourself in appsettings, not via package. Then things got advanced ;) Great video
Amazing stuff, wasn't aware of a such nice package until recently. Great video!
Thanks! That is a great way to do complex A-B testing! Thanks again for sharing!
That is a very good explanation as usual my mentor , i think i will use a lot of your info in my next tech post ❤🎉
We use features/toggles concepts to customize ui for different clients as well as enable all for premium clients
Feature flags is very useful if you are using trunk base development (TBD)
Really interesting feature as always ! :)
Would you like to show us the "AddSessionManager" too ? :D
Great stuff, I decided to opt to use an enum to define the constants rather than const strings for the feature names. Though it's still going to be suspectable to breakages should the name be refactored. Meh, it's on me in this project. It's something small I'm making for myself.
I wasn't aware of this, I'll make sure everyone in my team is :)
I think you didn't show the main reason behind this package which is making your web application extensible ... with external DLLs as a plugin. the things you showed in this video is achivable easily with IOptionMonitoring and IOptionSnapshot interfaces.
I think this is just a plugin management library.
Thank you for insights on this topic. Can you maybe elaborate further on this by explaining what is the best way of releasing some features for specific users. Maybe you could make a video on this topic.
For me, you're the Feature Manager ! :D
cool video, I used this package on previous project
One of the main reasons I see for this is trunk based developement versus other branching strategies like gitflow etc... wondering what you're thoughts are on that.
Exact my thoughts on this. If you use git flow then its barely possible you'd need features functionality. Ofc there are exceptions like when you want to use it for A/B testing or release some features only for specific group of users.
All other use cases like ability to enable/disable features on prod sounds for me kinda wrong. If anybody disagree with me would be interesting to read your points
Actually, I have the same thought. It would encompass this feature more in my development team, considering another branching strategy. Currently, we use GitFlow, but the team has grown so much that our Staging environment has become a bottleneck.
Therefore, I have also considered that using Feature Management at the version level might help manage a more transparent branching strategy between staging and production environments. For example, using the Trunk-Based Development (TBD) strategy, working with a single version Feature Flag and i would call it Version Flag, and if you want to work at a lower level, i will add a new level to use a feature flag.
I see great advantages with this approach, as it would help our Staging and Production environments focus on a specific version... So, it is also understandable that the team must be disciplined in keeping the code updated by cleaning up the legacy code.
Hey Nick thanks for the video.
Actually, I have the thought to use this feature more in my development team, considering another branching strategy. Currently, we use GitFlow, but the team has grown so much that our Staging environment has become a bottleneck.
Therefore, I have also considered that using Feature Management at the version level might help manage a more transparent branching strategy between staging and production environments. For example, using the Trunk-Based Development (TBD) strategy, working with a single version Feature Flag and i would call it Version Flag, and if you want to work at a lower level, i will add a new level to use a feature flag.
I see great advantages with this approach, as it would help our Staging and Production environments focus on a specific version... So, it is also understandable that the team must be disciplined in keeping the code updated by cleaning up the legacy code.
What you do think over this tought?
perhaps this could be a good way to release a new api version for endpoints. for the percentage setting, maybe a nice use case would be for a game of chance
Feature flag the feature flags
The PercentageFilter is clearly for prank purposes.
I use percentage features when I want to troll QA-testers. It's a lot of fun :)
Could i use my db instead on the configuration files with that nuget package?
yes you can, you have to implement IFeatureDefinitionProvider and then add it as Singleton, you can check their repo in custom feature provider section and learn more.
Nice overview, thanks! Is there any strategy on how to coordinate feature flags being enabled/disabled with frontend? I guess both BE and FE should manage feature flags at the same time in order not to be in the situation of enabled BE feature, which is not visible from FE, or, what is worse, disabled BE feature, getting called from FE.
Well done Sir. As always !!
We use Jason Robert's feature toggles library.
I've implemented something similar but using a Middleware, much more cleaner IMHO since I can explicitly inject services.
I use this in my project. The main problem is when you get too many, code gets a nightmare! You need to keep it to a minimum. The other issue is that we have it in Azure feature management (one for each environment). How can we override those configs for local development?
Create another environment called testing? Ideally separate one for each developer not to step on each other's toes
excellent video! thanks for sharing!
Thanks for the video, how it can work with logged in user role. If the user is an admin show feature otherwise hide it?
I have used FeatureGate attribute for NET 6 and had an interesting issue: my controller actions where not called, but Controller constructor was being called. I had to use some of my dependencies as Lazy so they creation was not triggered when feature was disabled
Hi Nick,
Do the filters on minimal APIs allow you to have two srtup for yhe same route and uae the feature flag to toggle between them?
Hello, Nick! Does dometrain give digital certificates after completing your courses?
Yes
Hi Nick, Is FeatureManagement supported in .Net framework 4.8? I am unable to create a DI through autofac for adding the package to my service. Any advice on this please?
Would this be a viable solution for limiting features based on software license? Although the features would have to be retrieved from a license key or some other source.
What if I want to enable a feature for a specific user role or even for a specific user. hmm, wait a second that's authorization 😄
I think the use case there would be advanced users selected to UAT features
No, that is not authorisation necessarily, yes you have to give permission to the user to use that feature, but the main thing here with feature flagging is that with FF you can enable a feature to some portion of your users, by country, by age, by email range etc etc.
That's what we called role based authorization
Is it perhaps possible to load the configuration based on some parameters the application can test at run time?
I have a case for Feature management, but it's less about toggling them at runtime, and more restricting what's available based on whether the target database has been fully upgraded (i.e. all features are available), or not (unsupported features are disabled).
If not, this library is cool, but it's not for me.
EDIT I suppose I could conceivably do this using a custom FeatureFilter...
Yes, it is a little different than what was shown here but one way that I have used has been for asynchronous development. Different teams/services agree on a contract or condition and then it doesn't matter what order development happens, the consuming service can finish out their code first and have a feature flag that their dependency enables when ready.
For your use case, as I understand it, the target database would be like that dependent service, so your DB upgrade process could enable a flag when complete that your application can then consume. Any production Feature Flag services - for example the cloud-based ones that Nick mentioned - will have both SDK and REST options for setting the feature flags rather than only reading them.
Currently using Launch Darkly. Is there a world where I would or should use this with Launch Darkly?
So it's basically IOptionsMonitor with a different name, and some extra helpers for endpoints?
That was exactly my thoughts! At least with the Options you can create your own Feature object that implements a time frame, a percentage....
@@alfflasymphonyx Exept it's a little for than that. For example, we have a implementation of a `ISessionManager` that looks at the HTTP request headers to determine wether a feature should be on or not, this overrides whatever comes from configuration. And so you could have multiple of these `ISessionManager` polling multiple sources if you would so like. This can also include specific user/session information, ect.
I think this is meant to separate between the responsibility of the configuration and feature management but yes all of this can be achieved by IOptionMonitor
That is so cool. 😍
Nice, thanks for sharing, We use this FeatureFlags for functionalities on our API's, however never used for endpoints, maybe would be nice to show how the Swagger looks like when you have the entire endpoint behind the featureFlag, it might be tricky if the flag is off and you use the swagger json to configure Azure API Management for example.
We need the Rider’s New UI to be activated :P
What is the difference between feature flags and ISnapshotOptions？
Could have sworn u already did this video
How to change config value in app deployed into kubernetes?
Could you use this for Blazor UI stuff. Show and hide things based on the logged in users subscription level?
You should just use an component for this
What about multi tennant
Cool! Я хотел бы увидеть интеграцию этой библиотеки с MediatR. Это было бы круто!
Excellent video. Thanks Nick.
Could you do a video on Custom fields?
Say a small contacts table where one company wants to list whether the contact is a smoker, gender, availability, etc and another company wants to log passport information, Dob, etc?
A good usage of the percentage flags would be to deprecate an endpoint over time by making it fail gradually over a period.
I just dont get this flag is just 1 or 0
Funny how the minimal API at the end was way more verbose than normal controllers. Still not using minimal
This function is almost useless or at least very bad practice in fair amount business scenarios.
1. You should not allow anyone just go to production portal and configure something which dramatically change a production without easy to investigate trace.
2. You should not listen to so called on fly appsetting change, as if you do that, in quite a lot of cases, your site/product will need to restart. Then what will happen to the users connected to your site/product? Suddenly they will lost connection.
3. If you put this in appsetting, and your site runs multiple instances, you will need to manually go update all these sites. BAD
4. If you put this in some central place and your site listen to the change, suddenly all the sites/products listen to this will all restart and your sites are all down. Evil.
There may be some usages for this, but in the industry I am in (finance and data), I can't see any suitable scenarios for my work.
If you want to enable some feature, do a deployment or use some other technique, but not this feature management
The use of the appsettings is usefull most for development. In production, the use of something like Azure App Configuration let you manage this with auditing and security in mind. And it doesn't restart the app, but configures multiple path in the app.
We sometimes use this to toggle some feature for test/acc/prod, but do so with a pullrequest and an actual redeploy. I always wondered why we use this package when its basically just the options pattern without using the on-the-fly changes. I guess because it's called FeatureManagement?
Agreed with most of your points, but I think the way @JeffryGonzalezHt seems to use it sounds like a decent way to about it as well though.
1. Add tracing
2. The idea is that it should provide runtime toggles. If it doesn't, well, don't use it.
3. Put it somewhere else
4. See 2
@@JohanBenschop Another team demonstrated this App Configuration service together with this feature function some months ago and it was rejected by the company I work in.
The problem with App config Service is that unlike keyvault, the value needs to be readed in periodically. Then the DI will also need to handle the change.
It didn't provide enough value or at least evidence to support paying for this App Configuration Service.
He addressed almost every point in the video.
About TimePeriodFilter. Am I right it resets every time I redeploy the application? I can't imagine a use case for that, I probably do not want the timer to reset on every deploy.