Feature Toggling and A/B Testing with Serverless & React

Note: This article assumes you have a basic understanding of the Serverless Framework and React

Every 10 weeks, our team work on “hackathon” projects, which allow us to dive into new projects and technologies that benefit the organization, but are exploratory in nature, and let us have fun learning new things.

Our latest hackathon tackled something that we have seen the need for within our applications: the ability to turn on and off features with the flip of the switch, as well as control what percentage of users see what features.

Feature toggling is a key tenant of Scaled Agile — it allows us to “release on demand”, meaning we can push code to production at any time, even if it hasn’t been completed, then turn it on whenever it is ready.

A/B Testing, at least in the sense that we are using it, is testing different versions of features to see how they performance against each other.

Just Get to the Code Already!

Okay, here goes.

Our feature toggle setup relies on a basic AWS Serverless stack (API Gateway + DynamoDB + Lambda) on the backend and a static React frontend (stored in S3).

The Backend

Here’s what our serverless.yml file looks like: https://gist.github.com/bjclark13/6ed31b6f976dd54c71095df5a47334a6

The back end is pretty simple, it has basic CRUD endpoints for features. The real crux of the logic is in the GET request:

(See the full handler here: https://gist.github.com/bjclark13/d418e8f4a2b4830b209521b539875a90)

Here we have two types of features: A/B and Toggle (simply on or off). If it is an A/B test, then we storage a percentage of the audience that we want to display it for.

If it is a toggled feature, that simply means you either set it on or off based on whether the feature is enabled.

The endpoint will then return a JSON object containing the list of features, and whether they should be on or off.

  "FeatureAdminLink": 0,
  "DevotionalImage": 1

The Frontend

The React code has two main parts: the implementation of the feature toggling, and the admin interface for creating new feature toggles.

Our Feature component is an element that can wrap any other elements. It makes a get request to the API to check if it should be on, and if it is, then it displays the inner elements.

<Feature featureName="ReallyCoolFeature">

This is one of the things that is super easy with React, you can just have a state to determine whether or not to show the inner contents:

render () {  return(    this.state.isVisible ?      this.props.children    : null  )}

You can see the full feature component here: https://gist.github.com/bjclark13/79b8895628a35338bb0ae7e66203e237

The admin interface utilizes https://material-ui.com/ and https://github.com/aws-amplify/amplify-js. Material UI makes it easy to build pretty interfaces, and Amplify handles authentication for making API requests.

To Sum It Up

We quickly learned that feature toggling, while incredibly valuable, is not that difficult to implement. This would be advice on anyone trying out an idea — start with something small and simple, so you can quickly determine how meaningful the thing you built really is.

Our Daily Bread Engineering

Engineering blog for everyone’s carb-based devotional

BJ Clark

Written by

BJ Clark

Our Daily Bread Engineering

Engineering blog for everyone’s carb-based devotional