Comment by joaohaas
1 day ago
Literally all their examples can be replaced by some sort of:
if redis_client.get("staging.feature-flag"):
...
For frontend you add an endpoint that exposes this value.
I guess their frontend for managing these is 'nice', but at the end of the day it's a static page that sets flags on redis.
The flags are often not static, though. Varies between environments, markets, user cohorts and whatever rules you can come up with.
So plenty of parameters that could be exposed in Redis as well. No?
How do you edit them once it becomes complicated? Should everyone have access to everything, or do different teams own different toggles? How do you know they're unused and can be cleaned up? How do you roll out to 1 % but keep it persistent so that the same user has the feature on throughout?
All of these are of course possible to solve. But at some point just use something battle tested..
What else do you need for feature flags?
For one app and one team, honestly not much. It starts to matter when you want gradual rollouts where the same user stays in or out across services, different rules per environment or customer, an audit log of who flipped what when something breaks, and a way to find dead flags. And then the boring parts: not doing a network call on every check, and what happens when the store is down.