Azure App Configuration as a configuration provider in .NET6 apps — Part 3: Hot-Reload

This article is part of a series:

• Part 1: Basics
• Part 2: Options Pattern
• Part 3: Hot-Reload

This is the final part of the series and in it we will improve on the previous code by implementing hot-reload, so that we can propagate configuration changes from Azure App Configuration automatically.

Did you see it mom?! — Yep, that was a reload right there son. — Hot daamn (photo by Z. Macháček)

How do we do it?

App Configuration supports Event Grid which we will use to send on value change events via Web Hook.

I chose Web Hooks because they are very low level and although you can achieve this easier with Service Bus, by showing how to do this using a Web Hook we avoid the requirement of understanding how Service Bus works.

In case that you are interested how to do this using Azure Service Bus you can read this Microsoft’s article.

Let’s first revisit our DI setup and the values that we expect to have in App Configuration.

In Azure App Configuration we should have two entries:

1. Appc:Foo
2. Appc:FooSecret

Now that our API can communicate with Azure App Configuration we can move towards implementing the Web Hook that we need in order to be able to receive events from the Event Grid.

So, let’s implement a new route: refresh that will act as a Web Hook

That would be all the code that we need to have, so we can go and create an Event Grid Subscription, so that we can broadcast our App Configuration value changes.

In Azure Portal go to your App Configuration instance and under Events section create a new Event Subscription. Endpoint type should be Web Hook.

Endpoint value should be the endpoint that will receive the event from Azure and for an API that run on azure that would be something like: https://myapi.azurewebsites.net/refresh

but if we want to run our API locally we will need to use some proxy to help us, and for that we will use ngrok.

What is ngrok? ngrok is the programmable network edge that adds connectivity, security, and observability to your apps with no code changes.
More info can be found under Getting started guide

For our scenario we need to run this command:

.\ngrok.exe http --host-header=localhost 5096

this of course implies that we need to download/install ngrok executable and have our API running.

If all goes well in you should see something similar to the image below:

Now copy the forwarding address (one that ends with ngrok.io) and use it as a base URL value for the Web Hook, so final value for the Event Grid subscription endpoint should be: https://…ngrok.io/refresher

Upon hitting the Create button after a minute or so you should see the successful notification in Azure Portal

How does all of this work?

As you might’ve noticed our polling interval for the refresher is 1 day, and it’s there as a fail safe in case our API misses, or fails to process the change event.

To trigger a change event all we have to do is update a value by going to Azure Portal and upon save an event will be sent to the Event Grid Subscription we have created which in turn will forward that event to our API, by sending the event payload to /refresh endpoint.

Code behind the refresh endpoint has two parts:

1. Processing validation handshake which will happen when you are creating the subscription endpoint. More precisely we will receive SubscriptionValidationEvent and Event Grid API expects to receive a response that contains authorization code which was send in the request payload.
2. Processing the change event where we use IConfigurationRefresherProvider to force a configuration reload, which means that values that we have in IOptionsMonitor will get reloaded as well, meaning we have hot-reload!

Unfortunately we are unable to configure refresher to listen to multiple configuration values, for example this will not work:

x.Register(“Appc:*”, “configs”, true);

You will get no errors, but you will try in vane to get your configuration refreshed.

There is a GitHub issue opened about this problem, and if you are interested you can read more about why App Configuration team decided to not support this feature, at least not for now.

A workaround is to use the so called Sentinel key, which is basically a key that you will use as a refresh all values under a specific label, and that way you avoid having to register all the values that you need to watch in your code, but that does imply that if you edit some value in App Configuration you will also have to update the Sentinel key value to trigger configuration reload.

Final Thoughts

This concludes the series and I hope that it was a fun and useful read.

Thanks for the read and the time, and in case that the series were hard to follow there is a code example on GitHub that you can check out.