This is part four in a series of articles.

EDIT: my Feature Management Pluralsight training course is now available.

In part three I introduced the concept of feature filters. These allow features to be enabled/disabled based on more than a simple true/false configuration.

Currently there are 2 feature filters supplied out of the box, a percentage filter and a time window feature. You can also create you own custom feature filters.

Creating a Simple Custom Feature Filter

To create a custom feature filter, the first thing to do is create a new class, for example called “RandomFeatureFilter”. To create a feature filter you need to implement the IFeatureFilter interface from the Microsoft.FeatureManagement namespace. This interface has a single method called EvaluateAsync that returns a boolean result as a task. If this method returns true then the feature will be enabled. For example the following code implements a feature filter that will enable a feature at “random”:

using System;
using System.Threading.Tasks;
using Microsoft.FeatureManagement;

namespace WebApplication1.CustomFeatures
{
    public class RandomFeatureFilter : IFeatureFilter
    {
        public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
        {
            // Simple/ naive "random" implementation
            bool isEnabled = DateTime.Now.Ticks % 2 == 0;

            return Task.FromResult(isEnabled);
        }
    }
}

The next thing do do is register this custom feature filter when the app starts up, for example in an ASP.NET Core app:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();

    services.AddFeatureManagement()
            .AddFeatureFilter<WebApplication1.CustomFeatures.RandomFeatureFilter>();
}

The next step is to configure one or more features to get their status from the custom filter. To do this in the appsettings.json:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomFeature"
      }
    ]
  }    
}

Notice in the preceding config that the filter is referred to by name as “RandomFeature” even though the class is called “RandomFeatureFilter” – notice the “Filter” suffix is removed.

Also note that if you try and specify the fully qualified class name ”WebApplication1.CustomFeatures.RandomFeatureFilter” or ”WebApplication1.CustomFeatures.RandomFeature” you’ll get an error.

Specifying a Feature Filter Alias

Instead of using the class name (minus any “filter” suffix) you can also specify a custom name/alias by decorating the filter class with the [FilterAlias] attribute as follows:

[FilterAlias("RandomizeFeatureFilter")]
public class RandomFeatureFilter : IFeatureFilter
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        // Simple/ naive "random" implementation
        bool isEnabled = DateTime.Now.Ticks % 2 == 0;

        return Task.FromResult(isEnabled);
    }
}

Now the configuration can change to:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomizeFeatureFilter"
      }
    ]
  }    
}

Notice in the preceding config that when using an alias that the “filter” suffix is not removed.

Custom Feature Filter Configuration Parameters

If you want to pass additional configuration information to a feature filter you can do this. For example take the following config that allows you to specify a method of “randomness” of odd or even:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "RandomizeFeatureFilter",
        "Parameters": {
          "Method":  "Even"
        }
      }
    ]
  }    
}

To access this in the feature filter evaluation logic, a strongly typed settings class can first be created to represent the settings:

public class RandomFeatureFilterSettings
{
    public string Method { get; set; }
}

Notice in the preceding code that the property Method maps to the “Method” parameter in the appsetting.json. Also note that the property has a setter, if you only add a get then the property will always be null.

To get access to the config you can access the Parameters property of the FeatureFilterEvaluationContext that’s passed into the EvaluateAsync method:

[FilterAlias("RandomizeFeatureFilter")]
public class RandomFeatureFilter : IFeatureFilter
{
    public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
    {
        RandomFeatureFilterSettings settings = context.Parameters.Get<RandomFeatureFilterSettings>();

        if (settings.Method == "Even")
        {
            return Task.FromResult(DateTime.Now.Ticks % 2 == 0);
        }

        if (settings.Method == "Odd")
        {
            return Task.FromResult(DateTime.Now.Ticks % 2 != 0);
        }

        throw new Exception($"Random feature filter configured value '{settings.Method}' is invalid, must be 'Even' or 'Odd'.");
    }
}

Custom Feature Filters Based On HttpContext

You can also create a feature filter that uses information about the current HttpContext to decide whether or not to enable a feature.

For example we could create a feature filter to enable a feature or set of features when the cookie “beta” is present - for example to allow users to opt in to experimental features.

To do this, the first thing to do is create a feature filter class that has a constructor that takes an IHttpContextAccessor.This will be supplied in ASP.NET Core via dependency injection. This instance can be captured in a field and used in the EvaluateAsync method to access cookie information:

using System;
using System.Threading.Tasks;
using Microsoft.AspNetCore.Http;
using Microsoft.FeatureManagement;

namespace WebApplication1.CustomFeatures
{
    [FilterAlias("BetaCookie")]
    public class BetaCookieFeatureFilter : IFeatureFilter
    {
        private readonly IHttpContextAccessor _httpContextAccessor;
        
        public BetaCookieFeatureFilter(IHttpContextAccessor httpContextAccessor)
        {
            _httpContextAccessor = httpContextAccessor ?? throw new ArgumentNullException(nameof(httpContextAccessor));
        }

        public Task<bool> EvaluateAsync(FeatureFilterEvaluationContext context)
        {
            bool isEnabled = _httpContextAccessor.HttpContext.Request.Cookies.ContainsKey("beta");

            return Task.FromResult(isEnabled);
        }
    }
}

To register IHttpContextAccessor in the Startup.ConfigureServices method:

public void ConfigureServices(IServiceCollection services)
{
    services.AddControllersWithViews();

    services.TryAddSingleton<IHttpContextAccessor, HttpContextAccessor>();

    services.AddFeatureManagement()
            .AddFeatureFilter<WebApplication1.CustomFeatures.BetaCookieFeatureFilter>();
}

The final thing to do is configure a feature flag to use this new BetaCookie feature filter:

"FeatureManagement": {
  "Printing": {
    "EnabledFor": [
      {
        "Name": "BetaCookie"
      }
    ]
  }    
}

Now when a cookie called “beta” is present, the Printing feature will be enabled, otherwise it will be disabled.

Feature filters are a powerful way of providing custom logic that is also configurable. For example we could generalize the BetaCookie filter to be something like CookiePresentFeatureFilter and then add a configuration parameter that allows us to specify the cookie name.

Be sure to check out my Microsoft Feature Management Pluralsight course get started watching with a free trial.

SHARE: