We're really good at feature management at LaunchDarkly. But here’s the thing: because there's so much potential with feature flags and feature management, people can (understandably) get excited.
And we don't want to discourage that exuberance, because it can lead to amazing use cases. For instance, did you know feature flags can make your database migrations a breeze?
On the flip side, there are certain areas where we know that feature flag is not going to pay off in the way you might want. So, to help save you some time, here are some excellent examples of when not to use feature flags.
API secrets as variations
Most of us log into apps and sites each day using the standard username and password setup. Programmatically, you can also log in with an API, and there's usually an API key and API secret—the equivalent of a username and password.
In short, we do not want to put passwords or API secrets as the flag variation. Although it’s probably fine in most cases, it's just a bad practice in general—especially if you're going to be exposing flag variations to other developers or other areas of your application or even your users. You really do not want to be exposing API secrets as those variations, so don’t do it.
Configuration values needed at startup
LaunchDarkly SDKs and feature flags are part of the application. The application will start up according to some configuration values, at which point LaunchDarkly gets initialized and grabs flag values. So, if you end up trying to use flag values as that configuration, it's not going to work.
It’s sort of like a chicken and the egg situation. If you're not able to initialize LaunchDarkly until the application starts, and you're relying on values from LaunchDarkly to start the application properly… you can see the problem, right? You can't go back in time and get that.
It's worth mentioning though that there are already great configuration management tools out there. So, while there may be some overlap in potential functionality, LaunchDarkly tends to augment configuration management, not replace it.
Putting the feature flag directly in the functionality
Putting a feature flag directly in the functionality makes that functionality more brittle. As in, easily breakable, which is not ideal.
For example, let’s say you’re using LaunchDarkly to update tax rates in an app from 4.5% to 4.7% and use “4.7%” (percent sign and all!) as the flag value. That could break functionality if you're not sanitizing and checking to ensure your application accepts rate changes with or without the percent sign. If you're just doing that on the fly with feature flags, you’re bypassing a lot of the secure code review processes. This makes those sorts of variables or inputs a little more brittle because they’re more prone to human error, which is not something you want to do.
Additionally, it makes eventually removing the feature flag more difficult, because the flag value is part of your functional code. Instead, in most cases, your flag should be a decision point wrapped around your code without directly impacting the functionality.
Email blasts
Email campaigns are also a no-go. We've had plenty of people wanting to do experimentation on email campaigns, but LaunchDarkly can't be embedded where code can't be executed. Sure, if you can put LaunchDarkly in the code for your email provider and handler in the back end, then great! It just can’t go in the email itself.
Do you have a question you haven’t seen covered in this series yet? Feel free to reach out and let us know.
.webp)
