DEV Community

Cover image for Feature Flag manager in Rust - MongoDB Atlas Hackathon 2022 on DEV
Thiago Pacheco
Thiago Pacheco

Posted on

Feature Flag manager in Rust - MongoDB Atlas Hackathon 2022 on DEV

Table of contents

Introduction

Another Hackathon started and I couldn't miss this chance to contribute, connect and see what the community is building!
I decided to take this opportunity to learn Rust and MongoDB by building a Feature Flags Manager app.

What are Feature Flags?

The more an application grows the more difficult it becomes to deploy new versions of code and extra functionalities. That means it is extremely important to have a process that allows enabling/disabling functionalities remotely, without the need of redeploying the code. Feature Flags (also known as feature toggles) are a solution to that, which allows us to control remotely the rollout of features at runtime without affecting the code. On top of that, a solution like this also allows controlling to which users the functionalities can be enabled, type of rollouts and much more.

This process enables very powerful use cases such as A/B Testing, Canary deployment, Trunk-based development and Feature Toggle as a ‘Circuit Breaker’.

Category Submission:

Think Outside the JS Box

App Link

Demo

How does it work?

This solution allows us to manage Feature Flags and Environments.
It was built with the idea that every flag has a set of rules to be verified by the context of the caller.

Client's usage

Assuming you have the feature flag manager setup in your environment, your application can send a request to the FF Manager with a JSON object with the expected values defined in the system (these values are defined by you when creating each feature flag).

Sample use case:

Let's assume we have the following feature flag defined in the system:

{
  "name": "sample_flag",
  "label": "Sample Flag",
  "enabled": true,
  "rules": {
    "parameter": "tenant",
    "operator": { "Is": "tenant_1" }
  }
}
Enter fullscreen mode Exit fullscreen mode

Your application can send a request to the Feature Flag manager using the endpoint POST /flags

// Request
// POST /flags
body = {
  "tenant": "tenant_1"
}

// Response
{
  "sample_flag": true
}
Enter fullscreen mode Exit fullscreen mode

The client can also rely on a specific environment config by using the endpoint POST /flags/:environment_name

// Request
// POST /flags/<ENVIRONMENT_NAME>
body = {
  "tenant": "tenant_1"
}

// Response
{
  "sample_flag": true
}
Enter fullscreen mode Exit fullscreen mode

Admin usage

The admin dashboard allows us to create, edit and delete and simulate flags usage.
It also allows us to perform the actions above on environments.

To create a feature flag, navigate to the Feature Flags tab in the top left then click on the + button in the bottom right of the page:
Add feature flag

Once on the Add Feature Flag page, you are prompted with the following screen to add the flag:
Add feature flag page

You can add as many rules as you want, where each rule has a parameter, an operator and values.

  • Parameter: A parameter is a key to be expected by the client's context.
  • Operator: An operator defines how the parameter needs to be matched in the client's context.
  • Values: Values define what the parameter should be matched to. Here is a quick example:
// Rule definition
{
  parameter: "tenant",
  operator: "Is",
  value: "tenant_1"
}
Enter fullscreen mode Exit fullscreen mode

This rule definition expects that the client context contains the following content:

// client's context
{ "tenant": "tenant_1" }
Enter fullscreen mode Exit fullscreen mode

After adding the feature flag, you can simulate its usage by going to the SIMULATION tab, writing the JSON payload and clicking send:
Simulate feature flags

Environments management

To create an environment, go to the environment tab and click the + button on the bottom right of the page:
Add environment

Type the environment name and click save.

Once an environment is created, you can enter and customize the flags' usage in it by clicking on the environment name in the list and opening the edit screen.
Customize environment

A flag can be overridden by clicking on override flag:
Override flag

By default, if no customization is made, all the flags that are defined in the system will be returned according to their rules.

To simulate this environment setup we can visit the SIMULATION tab and send a JSON payload the same way we do for the feature flags simulation:

Simulate environment

Link to Source Code

Source code

Permissive License

MIT

Background

There are many feature flags management solutions today but, by having to deal with them for a while, I noticed that they are very overpriced for the problem they solve.

So I decided to take this opportunity with the Hackathon to build an open-source Feature Flag Management solution that can be customized according to your needs.

How I built it

This was a great opportunity to use Rust on a real project, so I decided to use the stack: Rust, React and MongoDB.

Rust was my first choice because of its speed, and security and because it brings a new paradigm to software development.
Even though it is mostly used for systems programming, rust has amazing support for web development with libraries like Rocket and Actix web.

MongoDB Atlas

MongoDB Atlas offers amazing tools to manage the collections and I used that throughout the whole development process.
The interface made it easy to test the queries that I needed to create and it helped me to learn the mongo syntax accordingly.

Backend service

The backend service was built with Rust, using the MongoDB rust driver to manage the database collections and using the Actix web library to create the endpoints.

Frontend

The front end was built with React.js, using the MUI library to have a nice and easy-to-build interface and React Query to handle API calls.

Additional Resources/Info

If you'd like to run this application locally, visit the main repo and follow the tutorial on how to use it.
Don't forget to read the READMEs in the Backend and Frontend folders as they have specific explanations if any customization is needed.

The application is in the very early stages and I would love to hear your thoughts about it. I am open to suggestions and contributions, so if you think this is a valid use case and would like to contribute, go ahead and create some PRs :)

Missing features and known issues:

  • Authentication and authorization are not yet in place;
  • Backend tests should rely on in-memory DB;
  • Create an LRU cache to make the response even faster for the clients;
  • Add Frontend tests;
  • Add frontend validations
  • Fix frontend autocomplete which requires clicking 'add' to work.

Top comments (0)