Feature request: Set of IFeatureFilters applied to all features about featuremanagement-dotnet HOT 5 OPEN

@jimmyca15 Here's a bit more detail...

Today we have hundreds of feature flags built on some custom .NET Framework thing. Way too many, TBH 😄 Developers basically add one for everything they do, defaulted to off/disabled. These are more like micro-features, a bunch generally group together to form something useful users would recognize as a feature. A deployment team is responsible for rolling things out and turning features on in prod. Usually, a set of features is demoed to some business user, who approves it before that rollout. The developers & qa use a browser extension to send HTTP headers to turn on/off features in development & test environments. For example, if you send X-TOGGLE-MYFEATURE=True then MYFEATURE will be enabled for your requests.

So I'm looking to port this application to ASP.NET Core, and I like FeatureManagement-Dotnet to replace our custom feature system.

• I'm using Microsoft.Targeting to turn features on/off for specific users in the demo phase.
• I've built a custom IFeatureFilter to do the http header thing.

That all works fine, but it's creating a lot of settings in our config file. It looks like this, but with 300 toggles:

"FeatureManagement": {
      "Feature1": {
        "EnabledFor": [
          {
            "Name": "HttpHeader"
          },
          {
            "Name": "Microsoft.Targeting",
            "Parameters": {
              "Audience": {
                "DefaultRolloutPercentage": 100
              }
            }
          }
        ]
      },
      "Feature2": {
        "EnabledFor": [
          {
            "Name": "HttpHeader"
          },
          {
            "Name": "Microsoft.Targeting",
            "Parameters": {
              "Audience": {
                "DefaultRolloutPercentage": 0
              }
            }
          }
        ]
      },
      "Feature3": {
        "EnabledFor": [
          {
            "Name": "HttpHeader"
          },
          {
            "Name": "Microsoft.Targeting",
            "Parameters": {
              "Audience": {
                "Users": ["[email protected]"],
                "DefaultRolloutPercentage": 0
              }
            }
          }
        ]
      }
}

Basically, it's a lot of JSON.

The ask on this ticket is really just to reduce some of that by using the defaults. I want to apply HttpHeader to all features, automatically.

from featuremanagement-dotnet.

We have a similar requirement to have a particular feature be enabled or disabled for an (automated) test. We found a way to use an implementation of ISessionManager to do this.

public class HttpHeaderFeatureSessionManager : ISessionManager
{
    private readonly IHttpContextAccessor _httpContextAccessor;

    public HttpHeaderFeatureSessionManager(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }

    public Task<bool?> GetAsync(string featureName)
    {
        var headerName = $"X-Feature-{featureName}";
        var headerValue = _httpContextAccessor.HttpContext.Request.Headers[headerName];

        bool? result = headerValue.ToString() switch
        {
            "enable" => true,
            "disable" => false,
            _ => null
        };

        return Task.FromResult(result);
    }

    public Task SetAsync(string featureName, bool enabled) => Task.CompletedTask;
}

This can be registered via services.AddTransient<ISessionManager, HttpHeaderFeatureSessionManager>();.

from featuremanagement-dotnet.

I'd like to understand more about the scenario. Are there filters being added in addition at the individual feature level? Are you defining other features at all?

Given that feature filters behave in an OR manner, any one of the "default" filters could result in a feature being on at any given moment. At a glance, this seems to me something application specific rather than a general paradigm that should be in the feature manager.

from featuremanagement-dotnet.

Thank you for the explanation. It is very clear now. So you do expect every feature to still be specified explicitly, that is good. You just happen to have a concept of "global filter" where the only necessary information is the feature name itself. Given that, we might be able to come up with a concept of global filters. We're about to release 2.2.0 but can look at it for a future release.

from featuremanagement-dotnet.

Sounds good thanks @jimmyca15

from featuremanagement-dotnet.