You must log in or register to comment.
Thanks for the article!
Another use case: It could be useful for one software deployed in more than one server and if admins want to enable/disable features specifically for every server.
Similarly, you can leverage this to wire traffic to DB replicas for instance. This if you need to handle traffic to DBs under specific scenarios (DB problems, burst of traffic, bugs, etc). So basically a purely technical feature flag (paying attention to authorization as always)
deleted by creator
Feature Flagsis a concept that helps to enable or disable a feature on an app. Example you would want to roll out a new button on app for a certain set of users, A naive and simplified implementation would look like something belowflags = server.getFlags() // Fetch/Compute feature flags if (flags.FeatureA == true) { // show button }Hm, I still not sure about this article lesson.
So, main issue is that users of old version can use new feature, but they should not? On a desktop app? But why they sould not be able to do it in the first place?
I mean idea is good, but situation described in article looks like completely fictitious or incomplete…
The scenario is not ficticious. It’s taken straight from my first job, but I had to leave out specific details. The application being developed had something to do with DRM, so that might explain the weird requirements.
The lesson is that sometimes business will require you to force users to update their version, and/or enable specific features for specific subsets of users. So you should have such a mechanism in place before it is required, otherwise you will end up doing hacky things like breaking the server to do what needs to be done.
Systems such as these are actually fairly common in enterprise, but since it was my first job, I had not planned ahead for this because I had no idea.
I am not sure what your tech stack implies (I know nothing about it) but I think you don’t really need feature flags, just better project planning and structure
