Feature Flags
At StashAway, we listen to our customers’ needs and constantly improve our product — leading to new features or enhancements. We may at times decide to roll out a feature on the mobile app but not release it on the web app, or have certain features toggled based on specific parameters, e.g. USD withdrawals for users who have USD deposits only. We have relied heavily on the usage of feature flags to smoothen the process and would like to share some lessons we learnt.
So, what exactly are feature flags?
A feature flag or feature toggle is a technique in software development that controls whether a functionality is turned on or off without deploying new code. Instead of maintaining multiple branches of code, a feature can be tested before it is completed and ready for release.
Maintaining multiple branches of code can be tricky, given that we have 3 different customer-facing applications (web/iOS/Android) and operate across multiple regions (Singapore and Malaysia currently). Also, maintaining various conditionals to display/hide certain features across all frontend apps can quickly end up with code bloat. Imagine a scenario where we only want a feature to be shown in version 5.6.x in iOS but remain hidden for web app, or only show the USD withdrawal form when the customer has made USD deposits.
The basics — how does a feature flag work?
In short — it’s a Boolean flag. Components in the frontend renders based on truthy values returned for the particular feature flag. This is demonstrated below:
Container has a set of feature flags passed in:
<Container features={{ SHOW_ELEMENT: true }} />Piecing it in NodeJS
The main library we utilise is fflip. Its simple and useful API makes implementation a breeze. In fflip, criteria are “rules that define access to different features” and features “represent special behaviours in your application”. Hence, we can compose feature flags using different criteria and it becomes very flexible.
Sample setup:
Given the criteria above, showBannerA will return true when a user is part of the test cohort ( allowedIds) and has more than $10,000 in total assets. Conversely, showBannerB will be true if user is part of the test cohort and does not have more than $10,000.
Our implementation
In our implementation, we added an endpoint that returns an object containing the various flags. Each app calls the /features endpoint on initialisation and then handles what is rendered to the user. In our sample below, we demonstrate 2 use cases — showing a toggle based on client version and USD deposit based on region.
First, we create the flags:
We create a criteria in fflip to differentiate apps deployed in different regions.
We create the corresponding feature flags:
Putting it together
We expose the feature flag via an endpoint, so it displays results below when calling from our Singapore webapp:
// /api/v1/features{ "ALLOW_USD": true, "SHOW_TOGGLE": true,}
We have a middleware that parses identification variables sent by client. We require that each call to the API be appended with a header that specifies the app and version. Our nomenclature for this is ‘app@x.x.x’ where ‘app’ is the application name and ‘x.x.x’ is the version.
We then create a controller by adding in `fflip`:
Add the controller method to routes which displays the results above:
Frontend implementation
Our frontend applications can then call the feature flags endpoint to determine which components to render. We created a higher order component to wrap these elements:
We can then easily wrap any element with this HOC:
Takeaways
While feature flags are a powerful feature to employ, care must be taken in maintaining the flags and not be overridden with too many flags everywhere. Once certain features have been safely released, the older versions of the apps should be made obsolete and we have to force the users to upgrade to a stable version.
We could also make use of this effective technique for A/B testing. We could randomly assign a feature and test the effectiveness of a feature, e.g. if a red button helps to improve conversation rates. The possibilities are endless.
Further reading
https://en.wikipedia.org/wiki/Feature_toggle
https://martinfowler.com/articles/feature-toggles.html
