Through this blog let us get introduced to Azure Function Proxies. This topic was covered by Kent Weare in Episode 15 of Middleware Friday.
Let’s discuss about Azure Function Proxies which provides “Reverse Proxy Functionality” for Azure Functions. Azure Function Proxies is quite similar to Azure API management. This episode is largely inspired by Matthew Henderson of Microsoft Azure Function Team. In his blog post – Azure Functions Proxies public preview, Matthew explains the reason behind why Microsoft came up with the ideology for Azure Function Proxies.
What is Azure Function Proxies?
The Basic ideology of Azure Function Proxies is that it allows us to define a single API surface for multiple function apps. Now any function app can define an endpoint that serves as Reverse Proxy for another API. The endpoint can be an function app or it can be anything else.
Reason for implementing Azure Function Proxy
For some users, it was difficult to manage large solutions with a single function app and there are a bunch of organizations using Azure Function in their microservice architecture with deployment between individual components. This case is related to each function app having its own hosting and there can be a lot different function app to keep track of it. We may also have some function app combined with other API but they could be in various regions, so what we end up doing is that we pass along a lot of that complexity down to our consuming client or consuming system.
So Azure Function Proxies come to the rescue by providing a unified URI (Uniform Resource Identifier) which client can actually consume and in the meantime, we would be abstracting all of the different function app or other API and it would also enable us to build our API at a faster rate.
Explanation
Initially, we create a function app by selecting the function option from the Azure portal. Here let us consider the case of creating an HTTP trigger for C# where the function of HTTP trigger is to invoke a function with an HTTP request. Now we create two functions, one being the PostTag which represents our post if we want to create a tag. The Code for the PostTag function is,
Then we create another function called GetTag with the Code specified as,
We use GetTag to pull the message from the queue and last tag value returns to the client.
We can select the link specified below to fetch the URL of both the functions. This link will provide us with Security Token for Authorization.
At this point, we move over to Function App Settings and enable the Azure Function Proxies having the latest proxy runtime version of 0.2. Consequently, we will select the “New Proxy” option from Function App Development which would enable us to create two proxies. They are Proxy GetTag and Proxy PostTag. The available options in proxy are,
- Proxy URL
- Route Template
- Backend URL
The URL specified in Proxy URL and the Route Template would be the same regarding both the GetTag and PostTag event. The Backend URL of Proxy GetTag will be related to GetTag event but for Proxy PostTag it would be related to PostTag event.
DEMO
Now let us consider the scenario, where we will use a function app to forward a message to a Queue. We will access the Function through its Proxy URI. Using Turbo360, we can access the Message from the destination queue.
In the demo phase, check the state of the queue which is specified as tags. Then there would be no messages in the queue during this phase.
Here we use Postman client to forward sample Tag Event messages to the queue. Then examine the URI to verify if it is the same as that of Proxy for PostTag operation. Finally, it sends the message. We will now receive a ‘201’ as a status to indicate that the API request is successful.
Moving back to the ServiceBus360 page, the “Get” option is selected, go to “details” where the tag values are displayed. We then pull the message from the queue and using the proxy URI, we will initiate a “Get” request. Now a tag value will be displayed which would be the same as that of the previous tag. Finally, the demo would be concluded where, when verifying with ServiceBus360 there would be no messages in the queue.
