Feature Toggles - Why and How to Add to Your Software

[@RahulChoudhary-jr7mu]

Awesome! Notification from this channel makes my day! Thanks for the great work you do!

[@rogerpetruki4759]

Loved the course, Good job!

[@MIDNightPT4]

Exactly what I was looking for!!

[@CodeWithSahand]

This video is absolutely priceless ✅

[@mykalimba]

I understand the need for having a feature toggle system in a product. Nearly every product I've worked on over the past decade has used a system like this (some more complicated than others). What I don't understand is how there's an open source solution for this, as every implementation I've ever used has been hand-rolled and purpose-built specifically for its respective project. I don't see myself ever switching to an external package to solve this problem.

[@vickylance]

What do you think that this open source solution lacks?

[@mykalimba]

@@vickylance Truthfully, I don't know what it lacks, because I'm not interested enough in it to look into it. I look at this the same way that I would view an "open source solution" for the customer database or the product catalog of my project. In my opinion, each of these things really needs to be specialized for the project, and will therefore be designed and implemented from the ground up. That's just the way I choose to do things like this.

[@vickylance]

@@mykalimba We use this tool in production for one of the largest banking applications and we did modify it a bit to suit to our needs and lifecycle. I think its very easily customizable for any needs as required rather than building from scratch.

[@xwdarchitect]

My thoughts exactly. The argument given in the video is that every code you write is something you’d need to maintain. However adding a 3rd party dependency to manage feature toggles (unleash) adds an external dependency to learn and maintain plus a potential point of failure which is btw somewhat out of your control. So there are trade-offs. And for simple sub-systems such as feature toggle management I’d stick with writing a custom solution. Especially in crucial infrastructures or banking apps.

[@increasingsun]

"Switching" context is hard to imagine. Now you are looking at learning curve, configurations and what not. But if the organisation wants to adopt the open source (again there are two versions, free and paid. As he said 95% of code is online, it is difficult to understand what 5% is not there apart from admin controls (top down) etc) and if it is free, it is as headache as building one. Paid version does solve your problem to a certain degree and when the sprint contains a lot of developers maintain the paid or homwgrown would be obviously difficult --> Again you might put restrictions on number of pushes to do and what not. Feature toggles per say is a good concept, provided used in smaller use cases and used hygienly. Set up for the same where you copy a prod set up, restrict the users based on IP or logged in status or country, maintaining a dashboard of active and inactive sessions, having approval mechanism, is a big project in itself, which is better when outsourced is what I feel.

[@increasingsun]

There is a difference between phased roll outs and feature toggles. Feature toggles never works for large deployment or monolith. Ofcourse you would have copy of prod setup and deploy it first there, iterate there and then push the master. But with so many devs pushing to prod, creating versions, testing and then managing it is a herculean task. With sprints, this goes nuts even more --> Mainly because the lagness in stakeholders testing and providing feedback, this creates versioning issues and creats a mountain to climb and prod push. This works for small pushes with phased manner and a/b at the end. Its a great combo.

[@thiagorossato2846]

Awesome video, lots of content. But I don't understood how can I deploy the proxy to some place like heroku

[@sulamoon777]

Great! Thanks for the video! What’s your vscode theme BTW?

[@silentspectator123]

Hey, How can I get the source code of the client application that you've created?

[@dark9615]

U r a hero.......a gods avatar....🙏🏻🙏🏻🙏🏻🙏🏻

[@JanDalhuysen]

awesome 🔥🔥🔥

[@boontawatkumpiroj5595]

It is good for client side feature toggle which you can't control the version, you can just turn off the flag without waiting for app store review or cache reset on web. Moreover client side can just release without waiting for server side deployment. But I don't think it would be great to be our new workflow, what will happen if you release an app with feature that is not done yet? If users don't update their app when you turn on the flag it's still break on the old version.

[@dputra]

Just add a prerequisite for that flag, e.g. app version. Sophisticated feature flag will even allow you to set how many users see the enabled feature, allowing gradual release.

[@papa_ethan]

THIS IS SO NICE.

[@saplay3372]

Great sir

[@_vs04]

@freecodecamp, please make API development course using spring/ spring boot (just like fast Api course)

[@JanDalhuysen]

epic 🔥🔥🔥

[@rssbasdf]

Great!

[@kzayman2952]

I am sorry but i can't unsee the among us crew in the thumbnail

[@samuellotz8304]

the font is so unreadable :(

[@afrasiab8576]

Well

[@LouSipher]

What in god's name is that font :(

[@matthewgreen3107]

Terrible in practice with more than a small team. We tried this with over 100 devs the amount of random breaking changes that held people up shot up through the roof. We went back to smaller features which were significantly better controlled releases and quality. Notice all the examples are simple UI / display outputs? Try it when some numpty adds a feature flag for a domain object that they have updated and removed a field that you was still using. The overhead of understanding the code paths and flags jumps through the roof! If you join a big team with long running work and they do this expect a headache, update your CV and leave. You will end up with a zillion API versions, you name it. Terrible.

[@SolomonTheStoryTeller]

Well said, we started doing this for every story/big ticket with our gigantic monolith at work to reduce bugs and oh boy, having nearly 100 devs do this with maintaining old path and new path is a nightmare. The code has become bloated after one sprint. in addition, you have to revisit the same code a sprint or two later to clean up the old path. I was searching online to find out where this insanity came about and I came across this video

[@dinoscheidt]

If you look at large teams doing this successfully, you’ll see that you have groom phases cleaning up feature flags. Also what many people don‘t tell you, you need to maintain feature flags in parallel to permission flags. Overtime the feature flags will be removed but the permission toggles will stay. I.e. every feature in your code base should have CRUD permission levels that later are assigned to roles (take a look at CERBOS as a new solution). Than it is very easy to delete stale feature flags from all places where also permission flags are used. If the point of the code you want to change is not a CRUD logic branch (I want to show something, create data, serve data, update data, delete data), don‘t try to put feature toggles at some random places within that block of your code but go upward to the next CRUD logic branch.

[@orinsoncarranza3459]

Tremendo

[@youssefkhedher3313]

❤️🚀🔥

[@ariseamazing8095]

I am 12 yrs and love this channel follow this channel

[@zxxczczczcz]

1 hour for just that

[@JanDalhuysen]

first 😉

[@silversurfer1967]

First here 😀

[@williamsuarez8853]

56:00

[@mayankvikash]

I didn't understood what is the use of these toggles, can anyone just tell me, what to do with this? (I haven't watched the full video)

[@AbstractCard]

Watch the full video.

[@disrael2101]

Same , intro sucks as wel

[@youssefkhedher3313]

watch this section 0:14:36

[@disrael2101]

@@youssefkhedher3313 still sucks explanation, can u try eli5 it

[@hafidzrahman328]

Sometimes u need to turn off new features in production when something happens on the run, that's the function

[@kiellsv]

Toggle who?

[@SolomonTheStoryTeller]

What an awful way to maintain a project. we started doing this for every story/bug ticket with our gigantic monolith at work to reduce bugs and oh boy, having nearly 100 devs do this with maintaining old path and new path is a nightmare. The code has become bloated after one sprint. in addition, you have to revisit the same code a sprint or two later to clean up the old path. I was searching online to find out where this insanity came about and I came across this video

[@SolomonTheStoryTeller]

@@AndreiGeorgescu-j9p we still do it lol and it is getting much worse. Most teams don't clean them up fast enough. so ya, maybe you are right. lol!

[@ariseamazing8095]

I wanna become ceo of Microsoft :)