A use case for implementing FTDD in a Full Stack JS application
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.
Motivation and struggling
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.
CODE !!
The code order will be according to the development order, but you may jump wherever you want:
- DB
- Node
- React
DB Structure
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:
feature.sql
role.sql
role_feature.sql
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 inrole_feature
table that this role has 2 features assigned to him, with specific properties-feature1
(feature id: 1), andfeature2
(feature id: 2). Each feature has different toggle property (on
field). One ison
and the other isoff
.
So, eventually, user ‘x’ should see thefeature1
feature but shouldn’t seefeature2
feature.
Node
The server side is responsible of 2 things:
- Arranging the list of features with there toggle properties, for the user.
- Block
off
features controllers
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 off
.
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 on
or off
.
If it is on
, continue regularly (next()
).
If it is off
, return forbidden response.
React (+ Redux)
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 user
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 on
or off
.
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
user
reducer
isFeatureOn:
Very similar to the server side, isFeatureOn
method is checking whether the feature we’re looking for is on
/ off
/ doesn’t exist.
What interesting here is the imported redux
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 user
reducer
, just like that: store.getState().user.features
.
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 FTDD!
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.
Top comments (1)
Wonderful , Thanks for the interesting content !