Table of contents
- Introduction
- What are Feature Flags?
- Category
- App Link
- How does it work?
- Source code
- License
- Background
- How I built it
- Additional Resources/Info
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
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" }
}
}
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
}
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
}
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:
Once on the Add Feature Flag page
, you are prompted with the following screen to add the flag:
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"
}
This rule definition expects that the client context contains the following content:
// client's context
{ "tenant": "tenant_1" }
After adding the feature flag, you can simulate its usage by going to the SIMULATION
tab, writing the JSON payload and clicking send:
Environments management
To create an environment, go to the environment tab and click the + button on the bottom right of the page:
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.
A flag can be overridden by clicking on 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:
Link to 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)