Categorization of Flags

[griffincox]

Multiple products at my company would like to use the same instance of Flagr for their A/B Testing. Currently, there is no way to separate flags by category (such as tag, product, or project). This is currently only possible by namespacing the flags like project1_some_flag and project2_some_flag - which would be difficult to manage with hundreds of flags.

Expected Behavior

Ability to filter flags by a category (tag, product, or project, the name doesn't matter)

Current Behavior

• No ability to filter tags by description, making it difficult to namespace flags like project1_some_flag and project2_some_flag
• No ability to filter flags by a category (tag, product, or project)

Possible Solution

Backend: Add another table: Categories (tag, product, or project, the name doesn't matter) and add a categoryId to all records so that they are filterable by category. UI: Make the flags index filterable and sortable by category.

Context

With a solution for this problem in place, multiple teams could use the same instance of Flagr because records could be categorized and filtered and sorted on those categories.

Enova International might be willing to write this feature as a PR to this project given some guidance as to the preferred solution.

Environment

All

[griffincox]

@mbryja

[wildefires]

This is something I've been looking into as well - we were thinking of adding namespaces so that you could set up things in such a way that you open a namespace and can see all the flags under a namespace. This also solves the issue of the flagr UI being very slow to load when you have a lot of flags - as you'd load the namespaces and then only the flags for that namespace once chosen

Additionally, we're looking into authentication and access control on flags, which would tie in well with namespaces - certain groups/people could be the only ones allowed to administrate flags/entire namespaces

[griffincox]

@Cull-Methi - that's exactly what we're looking for. It wouldn't be hard to do, but I'm sure there is a preferred way to do it...

[zhouzhuojie]

Thanks for opening this issue, I really like the introduction of namespaces. It helps to build better auth/permission and serve as a pretty good model for flags evaluation - for example, one can evaluate all the flags within a namespace without having to specify all the flag ids.

For implementation, if you have the bandwidth, please go ahead and open a PR. I'm also open to some UI design changes so that the web UI can demonstrate the concept of namespaces. Thanks

[wildefires]

Some questions about implementation: Should two disparate namespaces have the ability to give a flag the same key? Which is to say, should we change the primary key to be a composite PK, which would also require a change to the GetFlag and FindFlags APIs?

[wildefires]

Thinking about it, I guess the primary key is the ID currently - though the question still stands about whether or not the key field should be allowed to be non-unique (but the combination namespace + key is unique)

[griffincox]

I believe the key is is a uuid, and is always unique. So I think the question does a flag have one or many namespaces? I suppose a many relationship would be more flexible for future adopters, even if I don't need it in our usecase.

[mbryja]

After I briefly reviewed the database and API structure for flagr I believe that namespace can be made optional. Meaning there is no need for it to be part of primary key. The flag key needs to be unique and the purpose of the namespace is to allow better presentation and organization for UI. It can also be leveraged for access control.

[wildefires]

@griffincox the key is randomly generated, but can be edited by a user. Thus you could see a case where two different users both keeping a base_config key in their respective namespaces might be useful.

If we are to divvy up the UI with the namespaces where you only see flags from a given namespace at a time, it becomes difficult to know what you can/can't name your flags.

I would say a flag should have exactly one namespace.

In my head I'm picturing namespaces to be like directories on a linux filesystem and flags to be more akin to individual files - you could have "test.txt" in two different directories, but only one in a given directory

[dcramer]

347 could help here too

[wildefires]

I like #347 because I'm always a fan of opening up as much as possible.

The kind of categorization/namespacing in this issue could also potentially solve a performance problem - we have two environments for flagr, a dev environment for me and my team when changing things and the prod environment.

Our prod environment has about 30 flags in it so far, and our dev environment 1000+ flags in it (as a result of load testing we haven't cleaned up yet). The dev environment takes 4x as long to load the front page of flagr as a result of those extra flags (2.5s vs 10s). Having looked into the performance of it, it appears to be mostly in the JS (the DB still returns the data in milliseconds). Divvying things up into smaller chunks, where only the categories/namespaces are loaded first could improve that by a lot.

That being said this performance issue could also be solved in other ways (e.g. pagination), but would definitely be solved by adding this kind of namespacing

[zakazai]

for example, one can evaluate all the flags within a namespace without having to specify all the flag ids.

Maybe we can also extend it to provide an option where each flag can be evaluated either individually or as a whole namespace, something like Facebook's Planout here http://facebook.github.io/planout/docs/namespaces.html

[pacoguzman]

Hi there, we started to add tags to the flags in our instance. The first tag we added was one to identify the team owner of the flag owner:permissions so teams do not need to add that to the flag key and it's easier to spot on the UI which is the owner of that feature flags.

Secondly, as we decided to start using tags for batch evaluation we found that organizational tags very useful, as some service one to evaluate all their flags at specific points of the workflow on the running service and all of them at that time.

But what about other flags that they want to evaluate in other specific points, or set of flags which needs to evaluate at that point.

What we notice is that https://github.com/checkr/flagr/pull/369/files#diff-665ac40747224ecb4c1a83700c8eb690R133 is making and AND query so adding tags for the batch evaluation increase the number of tags, when on certain scenarios we would like to filter tags.

Does make any sense to add some some extra parameter to filter flags when making batch evaluations and using flags? flagTagsOperation to be or the default or and to satisfy this proposed behaviour. This is similar to the ElasticSearch match operator attribute.

Our idea will be to provide something like:

{
  "flagTags": ["owner:permissions", "batch:initial-load"],
  "flagTagsOperator": "and"
}

[github-actions[bot]]

Stale issue message