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.

▲ matsemann 2 days ago | parent | next [-]

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?

	▲	matsemann 2 days ago \| parent [-]
		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..

▲ stackghost 2 days ago | parent | prev [-]

What else do you need for feature flags?

	▲	ivarconr 2 days ago \| parent [-]
		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.