What is Feature Gating?
A bunch of configuration isolated from your application which can be used to enable/disable your app features. The configuration can be updated directly without a deployment in real time (if not, at least nearly).
Feature Gating gives you a lot of flexibility during production deployment. It helps you to have more control while shipping new features and enable you to perform Canary releases.
Feature Gating might sound overwhelming but at its core its just an If condition but you will discover how powerful it is.
When do you require Feature Gating?
- User Segmentation —There are two outlooks, One is that you are building an app to solve a very large problem but your client might just be interested in a couple of features. This could help you to experiment different pricing strategies & feature gating will enable you to bill users per feature basis. The second is that you might want to personalise the app experience for different user segments.
- Rolling out Experimental features — Deployments are time consuming and its painful to rollback post a bad release. It makes sense to have enough knobs configured on your system/app to tweak in almost real time. You can keep new features hidden until product and marketing teams are ready to share.
- A/B Testing & Canary Release— Simply you might want to roll out a new feature for a limited set of users or a workspace. You can run tests with a smaller group of users and once you are happy with the feedback you might want to rollout instantly to others as well without making any changes. Often there are marketing driven releases which are quite time sensitive, it can be mitigated by making releases before in hand & enable them later.
Firebase Feature Gating
There is no direct support or product Firebase provides for feature gating. I find Firebase really good fit for a Feature Gating. If you want to implement feature gates for mobile applications then you should definitely checkout Firebase Remote Config. It is projected by Firebase for controlling the behaviour and appearance of your mobile app but nobody is stopping you to use it to control feature gates. Also Firebase Remote Config comes with control over caching policies to ensure these changes are propagated smoothly. There is AB Testing platform built over Firebase Remote Config allowing you to conduct experiments as well. Its a kickass tool for engineering & marketing teams to optimise the app experience & understand user behaviour by running marketing experiments.
Note — All the above features are available for mobile (Android & iOS) and not for web.
If you are developing for web (Like I do) then you can use Firestore as an alternative. Its just like any other data collection on Firestore you are listening for real time updates.
Firestore gives you everything required to design your own feature gates. Its just about your application making a connection to the firestore at a given path where all your configuration lives. You can then listen to events and propagate the changes wherever required.
Feature gates can be structured to suit your requirements. I create multiple collections for different environments, I do keep a default collection, so that you do not need to replicate documents at multiple places. Then the next level you can have is workspace if you have multi-workspace app like Slack. Or it can be user level as well.
What I love the most about Firebase is the web firebase console where you can visualise your store and also edit directly. You don’t need to really create a separate UI to manage your feature gate config.
Once you have the config loaded into your app then you can make decisions whether to load a specific component or not. You can choose to hide/disable certain feature based on the config for the specific environment.
Things to keep in mind when you design the config
- Add defaulting as much possible, there should be base config always.
- Default should always either be true or false for all features. Keep this consistent across the config to avoid mistakes. If you want to have different logic, then name the keys accordingly like — Instead of dashboard: true or false, use enableDashboard: true or disableDashboard: false. Naming is very important to avoid confusions.
- Have higher order groupings so that you don’t alway have to go and disable for users individually.
- Feature gating everything can go wrong. Only feature gate independent & atomic components or features which should not disturb the overall app functioning
- Feature gate in advance, don’t wait for somebody to convince you that there might be requirement in future to enable disable for a specific client or demo. Just Do it.
Hope this gave you a direction to think how to design feature gates for your application with Firebase. If you have something to share or ask please feel free to tweet at me.
(Originally published in codeburst.io medium)