Feature Toggles on a .Net Core API

This article is republished from my original Feature Toggles on a .Net Core API post on fantail.io.

This is my second tutorial on feature toggling.  You can read the first here.

There are many languages and frameworks to choose from when it comes to back ends - I wanted to make a REST service to deliver all of the Time Entries to my Angular application, and almost every language available has REST server capabilities.  I chose to use .Net Core (C#) and Java for my example app.  My background is in Java, and I was really interested to see how .Net Core works.  If you don't know, .Net Core is Microsoft's cross platform offering - it has the Windows-specific parts taken out and runs on Docker. Linux, MacOSX, and of course Windows too.  It can also be compiled on other platforms too, which is very handy.

Today I'll be setting up LaunchDarkly using the .Net libraries - I'll do the Java version later on.  LaunchDarkly provides some samples to help you get started, but I wanted to change a few things.  Just like I did in the Angular front end, I wanted to use a type to represent my toggles so that the compiler would help me if I misspelled anything, or forgot to remove a toggle from somewhere.  In C# this can be done with an Enum:

The Enum can be mapped to the String values used by LaunchDarkly:

In Java Enums can have properties, e.g. String values that can be obtained from each Enum value - I am missing this right now as it would save me having to provide a separate mapping from Enum to (slightly different) String value. There may be a way better C# way of doing this, please let me know if so! Anyway, using this I can set up the rest of the FeatureToggle class:

I want to take advantage of dependency injection for my REST Controller class, so I have a little setup to do in the Startup.cs file. Firstly I created a configuration class for the API key - LaunchDarkly lets you use two Environments with all plans, so you can have different toggles set in Test and Production. I'd like the correct API Key to be used in test and prod, and using .Net's configuration is a good way to do this. First off, the Configuration class:

This matches up with the configuration in my appsettings.json and appsettings.Development.json files:

When I start the REST API I want the correct LaunchDarkly key to be available to my app - and this is done through the Startup.cs class.  This is where all the dependency injection, configuration and initialization is done in ASP.Net.

The full class is available here.  When this class runs it will bind the LaunchDarkly configuration to an instance of the LaunchDarklyConfig class, and create a singleton FeatureToggle object.  It will also inject these objects where they are needed.  The LaunchDarklyConfig object is provided automatically to the constructor of the FeatureToggle:

public FeatureToggle(IOptions<LaunchDarklyConfig> optionsAccessor)

and the FeatureToggle itself is provided to the REST Controller:

public TimeController(TimeContext timeCtx, FeatureToggle featureToggle)

The full TimeController.cs class is available here, but the main bits are:

The FeatureToggle object gets injected into the Controller on line 18.  I store this object and then when Create or Delete Time Entries is called, check it to see if the feature is enabled.  This uses the LaunchDarkly client to give me the latest value from the server.  If the flags are not enabled I return an error message - a 404 not found, so the caller knows (thinks) there is nothing available.  As soon as I toggle the feature, the check passes and the rest of the code runs.  Too easy! 

So why don't I just deploy this API, then deploy a new version of my web UI that can use the new features?  Why fussing around with Feature Toggles at all?

Feature Toggles will take away any coordination problems putting this new feature live might bring up.  I can deploy my code and when I am satisfied it is ready, turn on creating or deleting time entries.  If it doesn't work for some reason I can immediately turn the feature off without having to roll back my deployment.  Later on (when I add logins and not just anonymous users) I can test the feature out in production by steering some people to the new feature.  I can even do this by named account or role using LaunchDarkly!  Finally using the toggles I can make sure the front and back end are turned on at the same time - no more hoping my back end finishes deploying before my UI!  I can deploy in any order, even weeks apart knowing that my API and UI won't accidentally expose this feature until I'm ready.

Next up I want to do a similar post covering how I implemented LaunchDarkly in Java.  See you then!

Adam Knight is an Auckland-based Senior Solution Architect in Equinox IT's Cloud business.