GO Feature Flag flag edition API proposal

[thomaspoignant]

Context

GO Feature Flag is a feature flag solution designed to enhance developer experience by enabling the use of feature flags within applications. GO Feature Flag primarily relies on editing configuration files for managing feature flags, offering a streamlined and lightweight approach. This method is well-suited for those seeking a minimal installation and configuration process.

However, while this approach is effective, it might not cater to all users' preferences. Some developers (but also POs, SREs, DSs) may prefer a more visual interface for managing feature flags. To address this need, after some discussion on the slack channel we have seen that there is a common need to build an API aiming to provide a flexible and extensible solution that allows for the creation of user interfaces on top of the existing feature flag management system.

API Requirements

• Expose CRUD endpoints to be able to follow the lifecycle of a feature flag (from creation to deletion).
• Audit the changes and be able to rollback the flag to a previous version.
• Keep track of who has done the changes (optional for now).
• Be able to add authorization layer on top of the API
  • The way we manage authorization should be compatible with multiple providers and not tight to any vendor or Opensource solution (we can probably test with something like Auth0 and keycloak).
• Considering that we are starting to think how to implement flag sets in GO Feature Flag it would be great to have this in mind when building the API.
• The API should return explicitly the type of the flag to allow the front end to display properly the UI.

Tech requirements

• API should be written in GO
• Data should be stored in a relational database (probably postgres).
• Here an example of a potential format for this API

[
    {
        "id": "f0000000-0000-0000-0000-000000000001",
        "name": "New Feature",
        "createdDate": "2024-09-24T19:32:26.334992Z",
        "lastUpdatedDate": "2024-09-24T19:32:26.334992Z",
        "lastModifiedBy": "foo bar",
        "description": "fverkdjghbwksb ldfscvkhkzbn",
        "type": "string",
        "variations": {
            "variation1": "value1",
            "variation2": "value2",
            "variation3": "value3"
        },
        "targeting": [
            {
		            "id": "f0000000-0000-0000-0000-000000000002",
                "name": "Rule1",
                "query": "targetingKey eq \"123\"",
                "variation": "variation1"
            }
        ],
        "defaultRule": {
            "name": "Default Rule",
            "query": "targetingKey eq \"foo\"",
            "variation": "variation1"
        },
        "metadata": {
            "dfhch": 1,
            "toto": "titi"
        },
        "disable": false,
        "version": "1.0.0"
    }
]

• To keep history we can use the trigger mechanism of postgres to store changes (https://www.cybertec-postgresql.com/en/tracking-changes-in-postgresql/)
• For every feature flag we want to keep some meta data to be able to understand what happened. The important ones are:
  • createdDate
  • lastUpdatedDate
  • lastModifiedBy

Next

If you are interested to contribute participating to this API definition, I would appreciate your feedback about this requirements and to know if you think we are missing something here.

All feedbacks are more than wel

[augustinasrce]

Some developers may prefer a more visual interface for managing feature flags.

At least in our case, flags are used not only by developers, but by POs, SREs, DSs, who are not always into changing json to turn something on/off 😄

In general good starting point! Do we have any requirements for UI? I've seen you already done something, could you elaborate on that?

[thomaspoignant]

That's a good point.
The main requirement for the UI is to be able to have explicitly the type of the feature flag coming from the API.
I'll add a few point about that in the original message.

[augustinasrce]

So all the values will be stored as strings, and converted/cast on demand (UI and config)?

Do we have any preferences for the framework that will be used for UI?

[thomaspoignant]

I was thinking to store the different variations as JSONB in postgres.
So we will be able to store any acceptable flag values.

[thomaspoignant]

Do we have any preferences for the framework that will be used for UI?

Forgot to answer to this one, for now the first iteration of the UI I am working on is react + react hook form.

[thomaspoignant]

The repository containing a raw version of this API is available here https://github.com/go-feature-flag/flag-management