Hi guys,
I've recently been playing for a personal project with Azure Front Door service and found a utility that would be great in my opinion. For those of you that don't know what is Azure Front Door service let me say that allows you to define, manage, and monitor your global routing for your web traffic by optimizing for best performance and instant global failover for high availability. This is the first sentence that appears in the documentation but you have many more functionalities like URL-based routing, URL redirection, URL rewriting, Multiple-site hosting, Session affinity, Custom domains, etc.
You have an API app
So, I want to expose how to maintain and evolve your API app providing access to different versions using Azure Front Door service. I assume you have an API app that is working properly fine and granting services to users worldwide and your host is in Azure or any other web hosting provider, doesn't matter at this point. Now, you want to add some more functionalities and some of your methods will change completely the response. This could be seen as a major change and implies a version change so how will you manage this new version to your whole community of users?
In this case, the best approach should be to maintain the two different versions and recommend to your users to, proactively and progressively, modify their applications to the new API version.
But, how will you deploy your changes to the internet?
If you modify your current API app, you will have to plan a shutdown time -seconds, minutes, hours or any other kind of time depending on your changes and your deployment way- and inform your users about it.
Another approach could be to deploy your new version as a new app in your hoster. This implies a different URL from the current app making your users be confused and increase the difficulty to modify their apps to the new version.
As we see, there isn't a completely good solution that covers everything. So, Azure Front Door service comes here to resolve our problems.
Configuring Front Door for URL routing
Azure Front Door provides us with the power of URL-based routing. This means that you can route your traffic based on patterns to different pools. In the case of your API app, we will consider that you deployed the new version as a different API app to avoid any disturbance for your users so you have two different pools, version 1 and version 2 API apps. It seems that now we are able to keep a unique domain and, depending on the URL parameters, use one or another app.
By default, Azure Front Door provides you with this URL so you don't have to worry about it although you want to use your own domain. Please, follow this article in order to configure your own domain.
Our pattern strategy to define our API versions will be configured in Azure Front Door, so we have to decide how we want to serve our methods. A common pattern nowadays is to add the version number in the URL like:
https://api.domain.com/v1.0/api-method
And that's how you will configure your routing rules. Let's take a look at the following screenshot with the most relevant parameters to configure. The first one allows us to set the URL pattern where we describe our version 1 API app calls. We must avoid the protocol and domain name of the URL and set the query like the following /api/v1.0/*.
The following parameter is the route type which defines how to process the request, in our case, you must select Forward and the proper Backend Pool. The third one I want to show you is "Custom forwarding path" parameter where we should type the URL of our API app to match with. If we open the API app for notifications functionality we should write here the relative URL to the notifications methods, /api/notifications/ as an example.
/api/v1.0/messages -> /api/notifications/messages
/api/v1.0/messages?$select(title,desc) -> /api/notifications/messages?$select(title,desc)
This is all the stuff you need to configure the service to provide with URL-based routing functionality. Moving forward, you are able to configure new versions of your API adding more and more rules and disabling or removing those that you don't need anymore.
Managing versions of your API app enabling or disabling routing rules is easier than starting or stopping API apps in different web hosting platforms or doing lines of code that reads an URL parameter and decides which response to send.
Consider this as a "Single Responsibility" pattern of SOLID principles where you have two clearly separated layers one for version management and the other for providing the proper functionality.
What else can do
As I said at the beginning of this article, Azure Front Door service provides lots of different functionalities you can take advantage of. If you want to evolve from here you can deploy your API app at several data centers and provide Geo-affinity and load balancing you your users depending on their localizations.
The following list provides you with links to the official documentation and I expose in this article:
- Azure Front Door Docs
- Azure Front Door Custom Domain Docs
- Azure Front Door Routing Methods
- Azure Front Door Routing Architecture
Hope you enjoyed reading this article. Please, leave any comment to help me and the community if you want to share something.
Top comments (0)