Feature Flags - Best Practices?

How do you use them without creating spaghetti code?

I want to use them to gradually roll out new features only to a small group of customers willing to try them out.


Bookmarking thread

I have nothing to add except +1 because I’d love advice on exactly this as well :sweat_smile: Thanks for posting it

1 Like

You have to treat them like they’re a feature in of themselves.

The feature is that you can customize the app through settings, the settings being the feature flags in this case.

There’s no other magic trick that I know, just need to be judicious in how you design them in your app.


It’s worth looking at libs that provide this functionality to apps. Even if you don’t use one, you can learn from their approach.


Here’s what we are currently doing: All feature flags are functions in a single namespace.
Business logic just uses these functions - and only these functions - at the appropriate location.

The location of the feature-flag data is abstracted away. We do allow side-effecting to retrieve the feature-flag.

More importantly - and something we need to improve - add a ticket to your backlog to remove the feature-flag if you add a new one.

The removal process is fairly simple: find callers of feature-flag fn, fix them and remove fn. Compiler will help you in making sure you didn’t miss a call location.

For the front-end, we have something similar in the form of re-frame subscriptions.

1 Like