search

serlo / backlog

1 stars 0 forks source link

☂️ Umbrella Issue: Experiments / Feature Flags #326

Open inyono opened 4 years ago

CarolinJaser commented 3 years ago

@inyono, I just found this while going through the API Issues. Is this still needed?

inyono commented 3 years ago

IMHO still something that would be useful (so that we don't need to re-invent the wheel / hack a workaround each time we want to easily toggle some feature), but not super important / urgent.

iMac7 commented 5 months ago

@hugotiburtino I'd like to look into this but it's not super clear to me. May I ask for more context and maybe the example flow of a serlo feature flag? (even better if it's been implemented elsewhere already) For example, A feature flag is represented as an environment variable. It is imported into env.ts in /server/utils (or a location everyone can agree on) and it is imported as a boolean.

Are there features already in the api that can have feature flags?

hugotiburtino commented 5 months ago

Thanks for asking. It is a quite exciting feature to implement this one.

The ideia is the following: after implementing a new graphql operation that is still experimental, we have to be sure that just some users are authorized to use it. So, we would need to add a helper function in the server authorization module and maybe in the authorization package to mark which users are allowed to use which experimental feature. The users could be just hardcoded, like we do in cache workspace, or they could have a role . After that, we would use the function as we usually do, v.g. here. It is also important that frontend can know which users are authorized to which experimental flag, so calling the graphql operation 

query { 
  authorization 
}

should also show it.