11–19 of 19 posts
Should you use a tool at all? One code file with the flags, and a small piece of router middleware that allows the URL to override the value of flags, and then just if statements. This has served me well on the past 3 frontend projects I have built.
So the URL can turn on different features?
This isn't a huge ordeal to DIY. A database table with some fields (name, on/off, dates) and a module to call that checks the db. A simple UI/API to CRUD those rows. If it's a SaaS, how does your app function if the SaaS is unavailable?
There's the local cache feature mentioned by shoo below, but more simply, there's also a fallback in the flag eval function, which looks like:
flag_value = LDClient.variation("flag-identifier", context_object, fallback_value)
As for DIY-ing it, I wrote about the pros and cons of rolling your own here: https://launchdarkly.com/blog/feature-management-platform-bu...
(TL;DR: Sure, you could build your own super simple one in a few hours, but it wouldn't have most of the features that make feature flags useful, and why bother when there are open source implementations already?)
This isn't a huge ordeal to DIY. A database table with some fields (name, on/off, dates) and a module to call that checks the db. A simple UI/API to CRUD those rows. If it's a SaaS, how does your app function if the SaaS is unavailable?
I've never used a full blown whiz-bang solution for feature flags, but when I stared at the launch darkly API one day it seemed as if: * feature flags were generalised as certain class of functions that made an on/off decision based on certain inputs, and the definition of these functions could be sent from the server to client services that had integrated the feature flag library. Functions could be refined at runti…
Both of these are true. See also my reply to the parent comment - you don't even need a local cache, since all flag evaluation calls should include a fallback value.
If you mean global feature flags, use the config file built into virtually every single webframework and and an if statement. It's really not complicated. Some webframeworks require an app restart for config file changes to be detected, or restart the app automatically when it detects changes to the file, so I've seen people use databases. But it tends to be an overcomplication and it's usually turned out to be a bit…
There's a huge amount of value in being able to flip a flag value and have the app react without a restart. The most basic scenario: being able to separate deploy from release. Deploy code with each major code change turned off; ensure the deploy's gone well, then turn the changes on one at a time (or whenever the feature is meant to go live). Not only does it make problem diagnosis much easier, but it means you don't need to rollback if one of them is buggy - just turn it off again.
But these are only feature flags in the simplest sense. Modern feature flag systems also allow targeting rules, which allow the flag to evaluate differently based on contextual attributes (e.g. something about the user). They also stream these rules to a simple local rule engine within the code so that evaluation isn't blocked on I/O. Then there's access control, experiments, multivariate flags...
Obviously I'd like you to use our service, but I'd rather that you find the one that best suits your business needs. There are plenty of good open source feature management systems out there. Just - whatever you do - don't fool yourself into building your own. Your time's worth more than that.
If you want a deeper argument, I wrote it up here, along with some examples of good open source systems: https://launchdarkly.com/blog/feature-management-platform-bu...
Theirs was dynamic in that you could change the rules and at a given interval the connected user's app would refresh and react accordingly. It was pretty complex, I suppose, but I'd roll out my own and go to something like them if I had a lot more conditions or targets.
KISS, you most likely don't need to use an external feature flag "hadron collider".
[1] https://www.martinfowler.com/articles/feature-toggles.html
This isn't a huge ordeal to DIY. A database table with some fields (name, on/off, dates) and a module to call that checks the db. A simple UI/API to CRUD those rows. If it's a SaaS, how does your app function if the SaaS is unavailable?
Hi - Dev Advocate for LaunchDarkly here. There's the local cache feature mentioned by shoo below, but more simply, there's also a fallback in the flag eval function, which looks like: flag_value = LDClient.variation("flag-identifier", context_object, fallback_value) ... where fallback_value is the value to be returned if there's nothing else available. As for DIY-ing it, I wrote about the pros and cons of rolling you…
In Rails if you have Active Admin, you just define the migration for feature flags and you are basically done. AA gives you a UI which you can protect with roles. Put a couple methods on the model and then you can toggle features anywhere in your code.
Our use case is very small, feature flags get deleted after all the moving parts are shipped and working. I'm sure your product has many more use cases and capabilities.