Lightweight Feature Flagging

Feature toggling or flagging is a powerful technique, allowing us to modify system behaviour independently on changes in source code. You can enable a feature only for selected visitors and other visitors did not know about it. In traditional world, new features are released to production with the code. The code is added, the feature is enabled. When you need to remove the feature, you remove the code. Feature flagging allows you to decouple the process of releasing the code and enabling the actual feature.

Such option is especially useful when you application spans across multiple platform and services. You don’t need to synchronise releases or ensure complex compatibility matrix.


Storyous, The only Point of Sale made for gastronomy

At Storyous we build Point of Sale. The thing that restaurants and coffe shops use for taking orders, communicating with kitchen, printing bills and much more. Our system is based on regular tablets with Android, web interface and bunch of web services.

Historically, when releasing new feature, we had to coordinate the release very carefully. All applications had to be prepared for various states of this feature being and not being there. We also had no real tool to rollout gradually or to specific group of customers. With thousands of clients with packed restaurants, this was major bottleneck.


Lean approach, the minimum viable product

First decision was done on where to store the actual flags. The configuration that defines what features are enabled and where. With only developers editing this file, you don’t need nice UI. JSON is good enough.

How do we store this file and how we make sure only the right people can update it? GitHub was practically made for this. You get the storage as well as user control and history records.

Current production version of our Feature Flagging configuration file.

In the file you can identify features enabled for particular environments, versions, tariffs or to particular clients.

Between the configuration part and various application stands the service. Simple REST API that receives various parameters, compares them to this JSON and returns the list of enabled services. Simple, huh?


Wanna more? Pay for that

If you need more or don’t want to waste your development resources, you can always use one of existing services that are much more advanced. Something like featureflow.io, launchdarkly.com, featureflags.io or ff4j.org

We’ll probably also end-up using one of these. The initial MVP was very important for us though. It helped us with our problem after spending just couple of development hours.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.