CODEWITHSUNDEEP
flagsfeature-selection
Brad Parks
Brad Parks

Reputation: 72283

Feature Flags - Should they be exposed to client applications?

I'm considering using Feature Flags in a web based app that has both javascript/html and mobile native clients, and am trying to make an informed decision on the following:

Should feature flags be exposed to client applications?

When discussing this with others, 2 approaches have appeared with how clients deal with feature flags, those being:

1) Clients know nothing about feature flags at all.

Server side endpoints that respond with data would include extra data to say if a feature was on or off.

e.g. for a fictional endpoint, /posts, data could be returned like so

enhanced ui feature enabled:

{
  enhanced_ui: true,
  [1,2,3,4,5]
}

enhanced ui feature disabled:

{
  enhanced_ui: false,
  [1,2,3,4,5]
}

2) Clients can access an endpoint, and ask for feature flag states.

e.g. /flagstates

{
  'enhanced_ui:true
}

Clients then use this to hide or show features as required.

Some thoughts:

Approach #1 has less moving parts - no client side libraries are needed for implementing gates at all.

The question comes up though - when dynamic flags are updated, how do clients know? We can implement pub/sub to receive notifications and reload clients, then they'd automatically get the new up to date data.

Approach #2 feels like it might be easier to manage listening for flag updates, since it's a single endpoint that returns features, and state changes could be pushed out easily.

Upvotes: 3

Views: 1571

Answers (1)

Vidmantas Blazevicius
Vidmantas Blazevicius

Reputation: 4812

This is something that interested me as well as I have a requirement to implement feature flags/switches in the product I am working on. I have been researching this area for the past week and I will share my findings and thoughts (I am not claiming they are best practice in any way). These findings and thoughts will be heavily based on ASP.Net Zero and ASP.Net Boilerplate as I found these to be the closest match for an example implementation for what I am looking for.

Should feature flags be exposed to client applications?

Yes and no. If you are building a software as a service product (with multitenancy potentially), then you will most likely have to have some sort of management ui where admin users can manage (CRUD/Enable/Disable) features . This means that if you are building a SPA, you will obviously have to implement endpoints in your api (appropriately secured, of course) that your front end can use to retrieve details about the features and their current state for editing purposes. This could look like something below:

"features": [
    {
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "defaultValue": "string",
      "inputType": {
        "name": "string",
        "attributes": {
          "additionalProp1": {},
          "additionalProp2": {},
          "additionalProp3": {}
        }, 
      ....

Model for features can, of course, vary based on your problem domain, but above should give you an idea of a generic model to hold feature definition.

Now as you can see, there is more to the feature than just a boolean flag whether it is enabled or not - it may have attributes around it. This is something that was not obvious at all for me to begin with as I only thought about my problem in the context of fairly simple features (true/false) where as actually, there may be features that are a lot more complex.

Lastly, when your users will be browsing your app, if you are rendering the UI for tenant who has your EnhancedUI feature enabled, you will need to know if the feature is enabled. In ASP.Net Zero this done by using something called IPermissionService, which is implemented in both, front end and back end. In back end, the permission service would basically check if the user is supposed to be allowed to access some resource, which in feature switch context means to check whether the feature is enabled for a given tenant. In front end (Angular), the permission service retrieves these permissions ( /api/services/app/Permission/GetAllPermissions):

{
  "items": [
    {
      "level": 0,
      "parentName": "string",
      "name": "string",
      "displayName": "string",
      "description": "string",
      "isGrantedByDefault": true
    }
  ]
}

This can then be used to create some sort of RouteGuard where if something is not enabled or not allowed, you can appropriately redirect for example to an Upgrade your edition page.

Hopefully this gives you some ideas to think about.

Upvotes: 4

Related Questions