FTDD (Feature/Flag toggle driven design) is a design pattern that helps teams to deliver new functionality to users rapidly but safely. Basically, it show/ hide features depends on the users role/ group/ whatever distinguishes the features set.
This pattern is the foundation basis of A/B testing.
For instance, with this ability, you may upload a feature to production in the Beginning of the development, hide it from anyone but you, keep working.
when you feel good enough about the feature, you may reveal it to the QA team only, and when they approve, you may reveal the feature to whoever else you want.
Before we dive into the code, let me share with you what motivated me to write this article.
In Castor, the company I work for, we are aiming for a full CI/CD.
As a small seed stage startup, with large scale system, its not an easy task. So we are always trying to find new ways and approaches for reaching this goal.
Few months back, I participated a very interesting lecture delivered by Igal Steklov about FTDD.
That was my very first experience with this pattern, and I swore to myself that I’ll implement this in my company.
It occurred to me that this design may benefit all our departments for a more optimized deployment. From the Development by deploying with less fear of major bugs, to the Product and the QA, by checking their new features in the production environment, prior to exposing them to the customers, and of-course, the managers technological mind set.
When I started to dive deep in the community for implementation approaches, I found myself with too many question marks. I found a lot of built in packages, small or big, free or not, but with a learning curve and code adjustments.
In addition, I found many tutorials and documentation about the design algorithm, but without enough code and architecture references, especially not in my stack.
And in the end, I realized that it would be much faster to build it by myself, without third party packages.
That’s why I decided to build it on my own, and share with all of you what I came up with.
My simple ask for you guys, is to have your feedback on my architecture design and code, please feel more than welcome to share with me your inputs, as we will ever be in a learning curve :)
In this article I will show my solution for implementing it in my React app.
In addition, I will show the implementation in the server side (Node), and the DB structure.
The code order will be according to the development order, but you may jump wherever you want:
So the first thing I've done is creating my tables in the DB. i’m working with MySQL DB, and I created 3 relevant tables for this:
With this 3 tables I can specify features for different users.
Example: lets say user ‘x’ is an
enterprise(role id: 7) user.
We can see in
role_featuretable that this role has 2 features assigned to him, with specific properties-
feature1(feature id: 1), and
feature2(feature id: 2). Each feature has different toggle property (
onfield). One is
onand the other is
So, eventually, user ‘x’ should see the
feature1feature but shouldn’t see
The server side is responsible of 2 things:
- Arranging the list of features with there toggle properties, for the user.
Lets see how I managed to arrange those features:
The above code shows the arrangement of features for the user.
The method returns an array of features, some of the are
on, some of them
This list will be sent to the client side, and will be used here, for the controller blocking.
These logic above shows the blockage of the controllers.
policies.js is responsible for every logic you want to add prior to the controller. For example, checking user authentication.
I added there a feature validation,
isFeatureOpenPolicy, which checks if the feature that relates to the controller is
If it is
on, continue regularly (
If it is
off, return forbidden response.
You may play with the features and see the code of the client side, in this codesandbox:
In the client side of the application I used a very simple methodology by using HOC (Higher Order Component).
This methodology allowed me to toggle features very easily by adding HOC to component.
To make it work we create a component for every feature.
Its not must, and I will show how I toggled features that are not a component and/or in other component or service
First, we need to store the list of
features that we got from the server.
I work with Redux state management, so the right place for me to store was the
reducer (that’s where I store all the initial user state)
OK, lets see the HOC:
This HOC is very simple:
It gets 2 arguments:
WrappedComponent, which is the component that wrapped with the HOC, and
featureComponentId, which is the feature id of the component.
It checks if this feature is
If it is
on, it returns the
WrappedComponent, like nothing happened.
If it is
off, it returns nothing (
<div/>), so the user wont see that component.
The HOC is connected to the
Very similar to the server side,
isFeatureOn method is checking whether the feature we’re looking for is
off / doesn’t exist.
What interesting here is the imported
store. By that, we don’t need to pass
features to the method, only the relevant
featureId, which is much easier.
We can default
features argument with the user
features from the
reducer, just like that:
Now we can finally see a feature component:
The interesting stuff here is where we
export the component.
That’s where we wrap our component with the HOC, and use FTTD!
Now for those of you who remember that I promised to show a non feature component case. here it is:
Very simple, just use the
isFeatureOn method wherever you want.
The next and following article will be on how I created the admin panel for the toggles management
That was my way of using FTDD in my full stack app. I hope some off you out there would find it useful somehow.