Feature Flagging in Ruby
Using EightBall

Marc Morinville | Last updated on November 24, 2021 | 2 minute read

Your team is working on a revolutionary new feature. It’s a very exciting time at work, but you know that, no matter how many precautions you put in place and how many tests you write, introducing a brand new feature to the production environment always carries at least some risk with it. What if it doesn’t scale the way you thought it would and you need to turn it off temporarily? Rolling back can get complicated, but rolling forward can take too long. Wouldn’t it be great if you could just… flick a switch?

You need feature flags.

Hold Up – What Are Feature Flags?

Sometimes called “feature toggles”, feature flags are a strategy for conditionally showing or hiding features in an application. Feature flags, in one loose form or another, have been in use since the dawn of Man (think of how a video game might handle expansion packs, or that horrible code your co-worker you wrote that only runs if (user_id == 86)).

Martin Fowler, as usual, has an excellent article on the subject dating back all the way to 2010.

In general, you would use a feature flag to temporarily enable, disable, or otherwise modify features in your application based on certain criteria. You could run a beta test with some customers who are especially interested in the feature; you could modify your subscription model for a set period of time to analyze the impact on revenue; you could deploy a half-finished feature so another company you are working for can start developing the UI — the sky’s the limit.

Before we get ourselves all worked up here, it’s important to remember that feature flags are a form of technical debt. You need to have a solid plan in place to include them safely, gather the data you need, and remove them once you are done. Otherwise, your code will become a hard-to-follow mess of branching statements, not to mention that testing all the permutations will become increasingly difficult.

You Should Always Re-Use Existing Solutions…So We Wrote Our Own

We needed feature flags at Rewind to introduce a shiny new feature. “Easy,” we thought. “Let’s go find an existing feature flagging solution that works in Ruby”. As we found, there are existing solutions. Lots of them, actually. The problem was we weren’t particularly interested in paying hundreds of dollars a month for someone to host a configuration file for us, or spinning up and maintaining an entire server to answer yes/no questions, or tying our entire data model to the feature flagging system. None of the solutions we evaluated met our criteria: free, easy, non-intrusive. Maybe we’re picky.

EightBall: Because You Ask It Questions

Magic 8-ball, should this person have access to our world-changing beta UI?”

We ended up writing and open-sourcing EightBall, a small Ruby gem to load up, parse, and answer questions about feature flags. In our case, we store a JSON file behind an auto-invalidating CloudFront distribution to make it quick and easy to update.

Our JSON file looks something like this

    “name”: “NewFeature1”,
    “enabledFor”: [{
      “type”: “list”,
      “parameter”: “userId”,
      “values”: [86]

and configuring it is simple:

EightBall.provider = EightBall::Providers::Http.new <CloudFront URL>
if EightBall.enabled? ‘NewFeature1’, user_id: user.id
    puts ‘Yup!’

If you have questions, find a bug, or have an idea on how to make EightBall better, feel free to reach out to us (or open a PR!).


We’re hiring. Come work with us!

We’re always looking for passionate and talented engineers to join our growing team.

View open career opportunities

Profile picture of <a class=Marc Morinville">
Marc Morinville
Marc Morinville is a software engineer who enjoys solving problems just as much as he likes reading, writing, and teaching others about them. He spends most of his free time worrying about how he’s going to spend time on all his hobbies, rather than partaking in any of them.