How is this any better then having a simple flag in the config for lets say dev mode? or on/off. if this comes to having to manualy ask if the feature is enabled or not?
Yes - you need to explore Targeting - github.com/microsoft/FeatureManagement-Dotnet#targeting And take a look at this: github.com/microsoft/FeatureManagement-Dotnet/blob/main/examples/FeatureFlagDemo/HttpContextTargetingContextAccessor.cs Basically, you can target the user's by their role assuming they are present as claims on the IClaimsPrincipal (which is populated from a JWT for example)
Hi Milan, Thanks for the video! I have a question regarding managing database changes. Specifically, if you applied an Entity Framework Core migration during the release and then updated some values in DB. I am just curious, how would you undo those changes in case a bug is found in the production environment? This is especially relevant if there isn't a staging environment or if the bug is only reproducible in production. I know, it should not happen in the prod but always something can happen
You can't undo database changes that easily, so this is something that needs to be planned very carefully. Essentially, if you keep your DB changes non-destructive, you will be able to revert the migrations.
We used somewhat simplified version of this in my previous job. We kept the feature flags in database. In that case, you get all the benefits, but you can also change the system behavior in real time because you only need to make a db change in order for the flags to be updated. What would be the upsides of your approach compared to what we've done?
Like he said, that are some funtionalities are already builtin like the percentage and or make sure that a service will remember if a user should see the feature or not. You coud also easily use this approach showed here with a database because its relies on config management from Dotnet which also allows to read from a database
My approach would be faster since it's reading from config files and not the database. But if you cache the flags, then it's even. You would also be missing out on feature filters and user targeting, so you will have to roll your own. The one I'm using for the website is pretty advanced and offers all of that, but it doesn't have a .NET SDK.
Feature flag in DB is costly and bring problems of handling the state and caching of the data, but everything depends on how it was implemented and what result you want. Usually resolving problems using less resources and simpler implementations are more compatible to a general purpose.
Thanks for your great video Milan. You are using antoher service for Front-End feature management. What if the websites wants to align the UI with the features available in Back-End. How should website gets the features available from Back-End or even from a specific user?
You might need to find a way to put on the video that this is for a usecase where you need more than ON-OFF switch for a feature. Enjoyed the video. on to the next one.
I heard you, recording one tomorrow, and coming out next week. It'll be more about SignalR though, but I'll connect it to a Blazor client. And I'll work on more Blazor content in the future.
Hi Milan, I'm confused, don't you think that this aproach could be achieve it using env vars instead of this package? I'm trying to implement the minor code as possible :) It's just a question, I like your video Cheers
For a simple on-off switch is possible it will be fine. But feature flags are much more advanced with feature filters, and the ability to pull the flags from different configuration providers.
When you make changes to the efcore models that would also necessitate updating the database tables, how do you feature flag so that even though the code is deployed, the change to the models is not released until you switch on the flag? I assume that for features that does something in different ways e.g calculating tax, one would create new methods instead of mutating existing ones and then use the feature flag at the handler level to choose the appropriate method. This begs the question that in real world, you might need to create a new modified copy instead of mutating existing code?
1 - You wouldn't control the migration with a feature flag, that's something that should be done manually 2 - Some duplication is expected, depending on how high or low level you want to place the feature flag check
Good one Milan. Is there a way to change the Featureflag value in production without redeploying the code when third party tools like Posthog not used?
Hi Milan, Thanks for the video. What if I want the feature flags to be stored on a DB or a distributed key value store so I can change feature flags states without restarting the service? can I achieve that with that package?
It looks so cumbersome, if you have 999 features, one is related to mapping, another to business layer, it would look like lots of ifs all over the place
Or, if you have well structured SOLID code and know how to leverage a good quality IoC container, you can implement a factory layer and use that to swap out/ decorate classes as appropriate.
Yes and no. When it just comes for checking if something is enabled or not, then you can easily use Options but if you want more functionality like showed in this video, this not possible with just bare Options. You would need to implement by yourself
If all you need is an on/off switch, then you'll probably be fine. But I would still opt for feature flags in case I will need anything more advanced in the future.
@@antonmartyniuk Oh yeah. You can use the free tier and they will give you an estimate of your usage after a week based on your traffic. I'm nowhere near the 1M limits 😅 And I have about ~60-80k visits per month
Feature flags can definitely be a great option. However, how do you manage the extra overhead? 1. Once a feature is completely rolled out, you would want to remove the feature flag from the .NET code. So you have to remove it from the appsettings and all the extra if-statements, possibly the injections of the FeatureManager if no other feature flags are in the class. This greatly increases work. 2. Your example is an easy one. However, for example if you are working on a big feature, which not only contains a change in the code, but also say a layout change, it can get messy and ugly pretty quickly, and also create much extra overhead. How do you manage this cleanly?
1. First step is to turn the feature flag ON for all users 2. You can then start cleaning up your code This is pretty standard with trunk-based development.
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
Really nice example
Glad you think so!
Great video. Thank you!
Glad you liked it!
감사합니다.
물론이죠
Google Translate says this is "you are welcome"
In any case, thank you so much for the support! ❤️
How is this any better then having a simple flag in the config for lets say dev mode? or on/off. if this comes to having to manualy ask if the feature is enabled or not?
Because you can connect it to a confog source that can be dynamically configured. For example, which set of users can see the feature
Hi. Do you know how to enable some feature only for users which have some specific role?
Yes - you need to explore Targeting - github.com/microsoft/FeatureManagement-Dotnet#targeting
And take a look at this: github.com/microsoft/FeatureManagement-Dotnet/blob/main/examples/FeatureFlagDemo/HttpContextTargetingContextAccessor.cs
Basically, you can target the user's by their role assuming they are present as claims on the IClaimsPrincipal (which is populated from a JWT for example)
@@MilanJovanovicTech❤
Hi Milan,
Thanks for the video!
I have a question regarding managing database changes. Specifically, if you applied an Entity Framework Core migration during the release and then updated some values in DB. I am just curious, how would you undo those changes in case a bug is found in the production environment? This is especially relevant if there isn't a staging environment or if the bug is only reproducible in production. I know, it should not happen in the prod but always something can happen
You can't undo database changes that easily, so this is something that needs to be planned very carefully.
Essentially, if you keep your DB changes non-destructive, you will be able to revert the migrations.
We used somewhat simplified version of this in my previous job. We kept the feature flags in database. In that case, you get all the benefits, but you can also change the system behavior in real time because you only need to make a db change in order for the flags to be updated. What would be the upsides of your approach compared to what we've done?
Like he said, that are some funtionalities are already builtin like the percentage and or make sure that a service will remember if a user should see the feature or not. You coud also easily use this approach showed here with a database because its relies on config management from Dotnet which also allows to read from a database
My approach would be faster since it's reading from config files and not the database. But if you cache the flags, then it's even.
You would also be missing out on feature filters and user targeting, so you will have to roll your own.
The one I'm using for the website is pretty advanced and offers all of that, but it doesn't have a .NET SDK.
@@MilanJovanovicTech Your answer sounds really cocky. Kind of rude.
@@RaZziaN1 If you think this is cocky, you're too easily offended 🤣
Feature flag in DB is costly and bring problems of handling the state and caching of the data, but everything depends on how it was implemented and what result you want. Usually resolving problems using less resources and simpler implementations are more compatible to a general purpose.
Thanks for your great video Milan.
You are using antoher service for Front-End feature management.
What if the websites wants to align the UI with the features available in Back-End.
How should website gets the features available from Back-End or even from a specific user?
You'd use the same Feature Flag services on both ends.
You might need to find a way to put on the video that this is for a usecase where you need more than ON-OFF switch for a feature.
Enjoyed the video. on to the next one.
The smart ones will figure it out 😁
Any plans to make tutorials on Blazor?
I heard you, recording one tomorrow, and coming out next week. It'll be more about SignalR though, but I'll connect it to a Blazor client. And I'll work on more Blazor content in the future.
@@MilanJovanovicTech That will be great, thank you so much for your efforts.
Hi Milan,
I'm confused, don't you think that this aproach could be achieve it using env vars instead of this package?
I'm trying to implement the minor code as possible :)
It's just a question, I like your video
Cheers
For a simple on-off switch is possible it will be fine. But feature flags are much more advanced with feature filters, and the ability to pull the flags from different configuration providers.
@@MilanJovanovicTech Thanks
Thank you ! What is its advantage over using "IConfiguration" and read directly from the appSettings ?
For simple on-off switch, you will probably be fine. But feature flags are much more powerful, when you need feature filters and targeting.
Great content! 👏
How would you control the flags per environment in the first approach (config file)?
I'd probably move them to Azure App Configuration
Do you know if we can use a database instead of appsettings?
@@MilanJovanovicTech Thank you. That was great!
When you make changes to the efcore models that would also necessitate updating the database tables, how do you feature flag so that even though the code is deployed, the change to the models is not released until you switch on the flag?
I assume that for features that does something in different ways e.g calculating tax, one would create new methods instead of mutating existing ones and then use the feature flag at the handler level to choose the appropriate method. This begs the question that in real world, you might need to create a new modified copy instead of mutating existing code?
1 - You wouldn't control the migration with a feature flag, that's something that should be done manually
2 - Some duplication is expected, depending on how high or low level you want to place the feature flag check
Good one Milan. Is there a way to change the Featureflag value in production without redeploying the code when third party tools like Posthog not used?
Yes, you can use Azure Config manager or some other service like LaunchDarkly, Optimizely
Hi Milan, Thanks for the video.
What if I want the feature flags to be stored on a DB or a distributed key value store so I can change feature flags states without restarting the service? can I achieve that with that package?
You can use something like Azure App Config, and yes you can update feature flags without restarting the backend
Thanks for this content and new features, awesome and i am planning to use for my next project..thanks and love it
You're very welcome!
Do you have a video with Feature Flags using Portal Azure / Feature Manager?
Nope
Hi Milan,
What do you think about making video about IdentityServer4 and implementing separate Identity server by using this library ?
How do we connect these?
@@MilanJovanovicTech
I guess just by creating separate Identity server via IdentityServer4 library. Or it is not good approach in your opinion ?
It's a really useful feature. Thanks for the video.
Glad it was helpful!
It looks so cumbersome, if you have 999 features, one is related to mapping, another to business layer, it would look like lots of ifs all over the place
That's the price
Or, if you have well structured SOLID code and know how to leverage a good quality IoC container, you can implement a factory layer and use that to swap out/ decorate classes as appropriate.
If we are not looking for the AB testing, do you think we could do this with something like Option?
Yes and no. When it just comes for checking if something is enabled or not, then you can easily use Options but if you want more functionality like showed in this video, this not possible with just bare Options. You would need to implement by yourself
If all you need is an on/off switch, then you'll probably be fine. But I would still opt for feature flags in case I will need anything more advanced in the future.
Very useful content. Thanks Milan.
Glad it was helpful!
Really nice call on the frontend and posthog. Something might be useful to me.
And I see you like using tailwindcss too, really cool css framework
They have a very generous free plan, worth checking out for sure. And yeah, TailwindCSS rocks 😁
@@MilanJovanovicTechtell me by secret: is the free tier enough for your website?
@@antonmartyniuk Oh yeah. You can use the free tier and they will give you an estimate of your usage after a week based on your traffic.
I'm nowhere near the 1M limits 😅
And I have about ~60-80k visits per month
👍👍👍
💪
Feature flags can definitely be a great option. However, how do you manage the extra overhead?
1. Once a feature is completely rolled out, you would want to remove the feature flag from the .NET code. So you have to remove it from the appsettings and all the extra if-statements, possibly the injections of the FeatureManager if no other feature flags are in the class. This greatly increases work.
2. Your example is an easy one. However, for example if you are working on a big feature, which not only contains a change in the code, but also say a layout change, it can get messy and ugly pretty quickly, and also create much extra overhead. How do you manage this cleanly?
1. First step is to turn the feature flag ON for all users
2. You can then start cleaning up your code
This is pretty standard with trunk-based development.
✅