Rebuttal & Addendum to "Build a minimal feature flags manager in under an hour"

John Nunemaker -

Last week, a post titled "Build a minimal feature flags manager in under an hour" was making the rounds in Ruby-land.

First, let's start with what I love about the post.

  • The blog design is great. No idea if it's a common template or from scratch. But I like it. Good spacing, code highlighting, line length, etc.
  • The post has a bunch of great ruby and rails related tricks in it — especially around boot-time configuration. I know I learned something.
  • The content is encouraging people to centralize & organize code around the concept of feature flags.
  • The API for checking flags is perfect (it matches flipper after all 😉).
  • Lastly, it encourages diving into code and making something better than it was before.

So, I don't write this post to dump on that one. I liked it.

But if I were feeling feisty...

I'd say it misses the most important point of feature flags — control at runtime. So I'd like to continue the original post with some additional (important) points.

Runtime Runtime Runtime

Feature flags are about modifying system behavior without changing the code. Despite all the great parts of the article I linked above, the end result can't do that.

You can count changing an ENV variable as not changing code. But the code in the article (as is) wouldn't pick up that changed ENV variable without a process restart — at which point you are ending runtime and starting over.

At a minimum, they'd need some sort of reloading of the features.yml file on a regular basis (e.g. every request, every N seconds, etc.). That would be a wee bit more work but would do the trick.

Pedantic? Maybe. But unless you've modified a flag without restarting or deploying your app, I promise you, you've never felt the control and power of feature flags.

Limitations

Changing a feature wholly on or off is great. But doing so releases a feature to everyone at once. One of my favorite things about common feature flag use is first enabling the feature just for me.

I can't tell you how many people I've talked to who do this and have said it saved their butt more than once.

But beyond the safety, I feel special because I can see something no one else can. It's fun. I can kick the tires in the real environment and double check that my assumptions for how the functionality would work are the same.

From there, I can gain more confidence by letting a few more people in — trusted customers or a small % of all customers. If everything looks good and support requests aren't flying in, then I can throw the gate wide open.

Time

My last point is time. You can have on/off in an hour if you follow the article. Maybe less if you are a fast copy/paster. But you'll never be able to build even the basics from scratch faster than you can bundle install flipper (a bundle add you won't soon regret).

If the only thing stopping you from using flipper is a yaml file, I'll make a yaml adapter for flipper (creating flipper adapters is easy) and you can peel out. Just let me know. 😁

Getting started with flipper via active_record, sequel, redis, or mongo is generally zero config and you'll get all the control and power of modifying features at runtime, without the limitations, and in less than 3 minutes.

Don't roll your own. Stand on my shoulders (or someone else's that are less hairy). Try flipper.