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.

3 Likes

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.

3 Likes

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.

2 Likes

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

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.