How Feature toggle enables developers to control app features on runtime.
Recently when I was working on an application, where a certain feature needs to be updated without affecting the same feature which will still exist in the previous versions of the application. Of Course, there must be a solution to handle this issue, because every application on the play store must have handled this problem somehow. So there I go to learn something new and take this as an opportunity to share my learning too, behold the power of Feature toggling.
So where do we use this so-called Feature toggling?
- Update existing features without affecting previous versions.
- Adding a new feature through several updates.
- Want to shut down a feature from the X version.
The above steps are pretty hectic to implement while the app is live in production. But these are vital for any fast pace evolving application, which nowadays is all of them.
So what is Feature toggling?
“Feature Toggling” is a set of patterns that can help a team to deliver new functionality to users rapidly but safely. — martin fowler
Yes, as good as it sounds. Feature toggling enables developers to rapidly deliver new features and updates to existing features all at the same time without affecting the stability of the previous versions of the application. This technique requires the implementation of both backend and frontend.
Update existing features without affecting previous versions.
Let’s see an example to understand this powerful technique in action,
In an E-commerce application, the current process of adding an item to the cart does not involve checking the inventory. But everything is fine, people are making orders and goods are shipped to them. At some point, due to the Corona pandemic; the import of goods has been banned. Suddenly the things on the site are going to be out of stock, so we need to make a change in the process where the system has to check for stock availability before people add items to the cart. To implement this process we need to check for the stock in the backend and display the result to the user on the frontend.
But the catch here is, people may not update the application to the newest version as soon as we push the new release. So we have to make sure the previous version doesn’t give an error or possibly crash while an item is added to the cart. This is where Feature toggle comes in place; If the toggle is turned on, users from the updated version will go through the stock availability check; And if the toggle is turned off, all the versions of the application will take the old process where there is no need to check for stock availability. So by using Feature toggle here, whenever there is a threat to stock availability we can turn on the feature to reduce invalid orders at the same time we did all this without affecting the previous versions of the application out there.
Like train track change we simply turn the toggle on to change the path and vice versa
Feature toggle works with some strategies like turning on the toggle for a specific set of people based on geographic location, age factors, versions, etc., One common strategy is version strategy, which helps deliver the feature to users above a specific version, users below that particular version will not get affected.
Version 4 having the current feature which doesn’t have to go through a stock availability check
Let’s suppose this feature released in version 4.5 and versions before 4.5 don’t have the feature toggle check. But the version on or above 4.5 can have feature control under the toggle
When the feature is turned on we need to specify the version strategy values states from which version this feature should takes place, as of I know there are version strategies for frontend mobile apps, backend services too
Even in mobile apps, you can’t expect the same version will be released in both android and ios platforms, so you can have separate version strategies fields for ios, android, and backend too
Adding a new feature through several updates.
Understand usage between production and development environments
Feature toggle may have advantages over runtime toggle which can be used for both development and production for different purposes, as seen in the above example it can be used in production live as a timely feature that can be toggled on or off at times.
Development these days is incremental, we rapidly deliver and deploy features to production, but we don’t want to show a feature in an incomplete state. For those purposes we can use the feature toggle as a key solution by turning on the toggle at development, production will be turned off until the feature gets completed
Example for feature toggles with the release train
D is still in development when the week 1 release happened and it is enabled in the next release but part of D is already present in the week 1 release in an incomplete state, D toggle is turned on once the development is finished on the week 2 release
Let's see an example of this kind of problems
Showing recommendation page in the app
We want to show a new recommendation page where users can see the recommended products and they can add to cart and check out to pay.
This is a long way journey and we can’t expect this to be delivered within the next release, this feature may develop across multiple releases. In those releases recommendations, the page will be turned off (prod).
We can build this feature under the feature toggle so that we can avoid showing it in the front end, and any backend endpoint we are building as new can be exposed based on the feature toggle.
There are cases when a feature is built during when the app is in prod, but due to testing, it is turned off in prod, at any time you can turn it on in production once testing is done. without any app update since the feature update patch is already been released and downloaded by users, they can use the feature once it is turned on
Want to shut down a feature from X version
We want to remove a certain feature from the X version but the old version still uses the feature so there are two things we need to maintain. We can completely remove the feature from the frontend in a single release but the backend tends to act for old versions. We don’t need to remove the corresponding backend since it will be continued on the previous versions. One catch here is we need to move this dependent endpoint inside a toggle to mention that a version strategy of below X version can have this feature and greater than X version will not be accessible
This is just an additional constraint just to prevent further conflicts, since we may have multiple consumers we don’t want to remove for all. For eg. only for the android app and for ios, web app this feature still continue to exists
you can specify this kind of parameters in the version strategy
We can see what are the opensource feature toggle service are available, which are widely used and sample snippets in the next post.