Feature Toggle/Flag Design in React.js and Node.js

A use case for implementing FTDD in a Full Stack JS application

source of idea: DevOps Zone

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:

1. DB
2. Node
3. 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:

1. feature.sql

feature.sql. every new feature gets his name, ON/OFF toggle property, description and componentId for future use.

1. role.sql

role.sql. list of roles to give for a user or for a group of users

1. role_feature.sql

role_feature.sql. assign features to roles and set the’re toggle (ON/OFF)

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_feature table 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 (on field). One is on and the other is off.

So, eventually, user ‘x’ should see the feature1 feature but shouldn’t see feature2 feature.

Node

The server side is responsible of 2 things:

1. Arranging the list of features with there toggle properties, for the user.
2. 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.

Comments

[Daniel Shaulov]

Wonderful , Thanks for the interesting content !