Simple cookie-based feature flags using Rack.
rack-flags ships in two parts:
- a simple rack middleware which detects the feature flag set for a specific web request
- a simple rack app for administering which feature flags are set for your browser
1. Add rack-flags to your Gemfile
2. Write a yaml file describing your features
foo: description: This is my first feature flag default: true show_new_ui: description: render our experimental new UI to the user default: false
3. Add the RackFlags middleware and admin app to your rack stack
In a Rails application, first add the middleware in
config.middleware.use RackFlags::RackMiddleware, yaml_path: File.expand_path('../feature_flags.yaml',__FILE__), disable_config_caching: Rails.env.development?
disable_config_caching is a boolean value that will cause the yaml file to be reloaded on every request if true, great for development
Then, mount the AdminApp to some route in
mount RackFlags::AdminApp, at: 'some_route'
Or, using a
config.ru something along the lines of:
require 'rack-flags' app = Rack::Builder.new do use RackFlags::RackMiddleware, yaml_path: File.expand_path('../feature_flags.yaml',__FILE__) map '/feature_flags' do run RackFlags::AdminApp.new end map '/' do run MyApp end end run app
4. Check the state of a feature flags when handling a request
For example, if you're using Rails you could do:
class SomeController < ApplicationController def some_action features = RackFlags.for_env(request.env) @show_whizzy_bits = features.on?(:show_new_ui) end end
Or if you're using Sinatra maybe you'd do:
get("/some/page") do features = RackFlags.for_env(env) if features.on?(:show_new_ui) render_new_whizzy_ui else render_boring_safe_ui end end
5. Override your feature flags in the admin page
Assuming you have a
config.ru similar to the example above you can visit /feature_flags in a browser to see the set of feature flags defined for your app.
From that page you can also override the state of whichever flags you want, just for your browser.
Subsequently when your browser makes requests to your web app it will see the overridden feature flag set.
This is a simple lightweight way to expose work-in-progress functionality to developers, testers or other internal users.
So wait, what is this doing?
The approach is described in this blog post.
Your app defines a set of known feature flags which are either off or on by default, using a simple YAML file. Users can override the default state of these feature flags just for their specific browser by visiting a special admin page. That admin page sets a special cookie which is interpreted by the rack-flags middleware. Your application asks rack-flags which feature flags are on or off for the current request. If there is an override cookie the rack-flags middleware includes that when reporting the feature flags states to the user.