Thanks for the video! In my previous job, we used to have some "hidden" frontend features on production that would be enabled by passing some flags as query params in the URL. Not really dynamic, but it helped POs and managers test out future staff while on production.
This is actually very interesting, lately I've been looking for something like this and it feels like perfect timing, every time I'm trying to implement something to my project you go out with another video with the exact thing that I'm looking for. Keep up w the content Cody!
great video, do you think it'd ever get cumbersome managing more than a few feature flags? Or would you just remove the flag all together once everything is functioning reliably in prod?
@Web Dev Cody we use this pattern in one of the applications I am working on. This application is based on system events, so we have millions of transactions per day. When we experience any problem and we have 100s of feature toggles, tracing through all these toggles, Is really hectic.
@@WebDevCody All these changes would merit a lot of risks(Testing, potential bugs). In my opinion using a gateway to version these features on the level of the deployment itself is a much better approach
![I.N "HALLUCINATION" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/n5B5q1Hwt_U/mqdefault.jpg)
Thanks for the video! In my previous job, we used to have some "hidden" frontend features on production that would be enabled by passing some flags as query params in the URL. Not really dynamic, but it helped POs and managers test out future staff while on production.
That’s an interesting approach. Seems like a simple solution which meets your teams needs
This is actually very interesting, lately I've been looking for something like this and it feels like perfect timing, every time I'm trying to implement something to my project you go out with another video with the exact thing that I'm looking for. Keep up w the content Cody!
great video, do you think it'd ever get cumbersome managing more than a few feature flags? Or would you just remove the flag all together once everything is functioning reliably in prod?
You remove the flags at some when your app decides the feature is here to stay and it’s been turned on for everyone for a while.
Good job babe!!!!! First!
Is this thing also called deployment patterns?
Maybe idk, I know the word canary releases is a deployment strategy
do you guys use a third party plartform to handle this or you implement it your self?
We handle it ourself
@@WebDevCody what would make you use a third party service to handle this?
What microphone do you use?
MXL 990
@@WebDevCody Thanks!
Awesome video. What theme are you using?
Bearded theme stained blue
nice job
How does one stay disciplined to learn coding
money to buy food with is one good type of motivation
testing in production is what twitter does nowadays ^
😂 savage
feature flags = commented code = trash in codebase
Feature flags are really troublesome and wouldn't recommend following that pattern
Why is that?
@Ca there are design patterns like facade or versioning with microservices that can be leveraged to do just that without added complexities
@Web Dev Cody we use this pattern in one of the applications I am working on. This application is based on system events, so we have millions of transactions per day. When we experience any problem and we have 100s of feature toggles, tracing through all these toggles, Is really hectic.
@@amgadtawfik7534 why do you have 100 feature flags? You’re supposed to delete them after they are deployed for a couple of weeks
@@WebDevCody All these changes would merit a lot of risks(Testing, potential bugs). In my opinion using a gateway to version these features on the level of the deployment itself is a much better approach