Add feature toggles/flags to MFEs

Owned by Binod Pant (Deactivated)
Last updated: Feb 10, 2022
3 min read

 

MFEs at edX are developed per guide at

Frontend Development . Visit this site for more MFE dev details

This page describes a few ways in which you can apply feature control to turn features on/off in MFEs

OPTIONAL: even if you use the methods below, you may consider combining them with the config method described here: https://github.com/edx/frontend-platform#application-configuration to abstract out how you are reading those vars.

Method 1: environment variables

For those using edx-internal to manage environment variables in MFEs, based on these instructions

You can read these vars via process.env.NAME in your code and use that to turn a feature on/off

Example: : Just consult the portion here, that uses the process.env.VARNAME

When to use this method:

  • when you need a feature switch for an extended period of time and don’t need to keep turning it on/off frequently.

  • goal is to remove switch and enable feature permanently at some point.

When not to use this method:

  • if you need to frequently test feature on and off in prod/staging. For that use the url parameter method

Also, avoid directly using process.env in UI component code, instead use the config to abstract where these are being read from, for example.

 

Method 2: url parameters

you can simply process url paramneters in your code and use it as a feature control switch boolean (ideally export it from a constants.js file or features.js file in your MFE)

Example: consult the hasFeatureFlagEnabled()function for an example. This one supports enabling a feature via a ?features=<name> url param

Here is a great example recently added by a 2U team member on how to use URL params (this is in shared Enterprise MFE repo)

When to use this method:

  • when you need to test the feature on/off in prod/staging frequently and the feature can be off by default

When not to use this method:

  • if you don’t want to expose the feature parameters to the external world. These are temporary anyway so hopefully you have a plan to remove these once you are done testing. If you do need to keep these permanently then maybe they should not be feature switches but proper url parameters or url path parameters.

 

Method 3: Obtain feature flags from API calls

In some scenarios, it may make sense to fetch feature flags as part of your API calls (usually this would be done during the initial ‘configuration' request that many applications make during or post initialization, but MFEs can make the best choice per their design. We are working on devising more consistent patterns here, but for now, you can use the following as examples:

  • TODO : Add examples of this

When to use this method:

If you want a longer term feature flagging controlled / centralized in your backend.

When not to use this method:

There’s not hard and fast rule here, but probably better to avoid building too many extra abilities code/infrastructure in your backend/frontend if you can leverage env variables for a shorter term feature flagging, or the url param method. Evaluate how many changes this will constitute. In the future, we may work on providing a more centralized infrastructure/library to make this easier.

 

Future/interesting ideas:

  • Support feature switching via Waffle. We already use Waffle for backend feature switches. Can we read MFE features switches from waffle so we don’t have re deploy MFEs just to apply var changes?

  • Github/Github actions? Can we find a way to apply vars from config and perhaps re-kickoff builds instead of having to create a PR?

  • GoCD?