In this blog, we will be taking a recap of Episode 15 of Middleware Friday where Kent Weare talks about “Introduction to Azure Functions Proxies“.
Azure Functions is a way in which you can quickly express an action. Microsoft defines Azure Functions as “An event-based serverless compute experience to accelerate development, scale based on the demand and simply pay only for the resources that you consume.”
In general, it’s difficult for customers to manage a large solution within a single function app. When you try to split the work into multiple function apps, it works for most of the triggers but gets trickier for APIs. Every function app has a unique hostname — therefore, keeping track of many hosts without a unified API surface can make things difficult for applications.
The public preview of Azure Functions Proxies exactly solves this problem by letting you define a single (unified) API surface for multiple function apps. This makes it easier to develop APIs.
The high-level architectural diagram of the demo is shown below –
The scenario shown in the picture above is almost similar to the one discussed in the previous episode of Middleware Friday. The difference being the Azure Functions Proxy sitting instead of the Azure API Management Layer. We will also have a GET scenario (in addition to the POST scenario from the previous blog) to poll the latest Request Tag from the Service Bus.
Let’s get started with creating the Azure Function App. For the purpose of this demo, we will create a function app with two triggers (POST tag and the GET tag) with the hosting plan based on consumption.
In this step, we will create a new function and define the naming conventions.
That’s it! Let’s see this in action by sending some messages into Azure Service Bus Queue and retrieve the message from the queue.
For this test, let’s use POSTMAN to trigger a Request. In POSTMAN, select POST and enter the Azure Function Proxy URL (the unified URL that we receive in Step 15). Click Send and you will notice a 201 Success code indicating that the message request has been successful.
Now let’s see if the request is available in the Service Bus Queue using Serverlesss360.
Similar to Test 1, we will use POSTMAN to trigger the GET request. The request will fetch the latest request value from the Service Bus Queue.
Now that we have received a message from the Service Bus Queue, we should not be seeing the message in the queue. Let’s verify this using Serverless360.
With Azure Functions Proxies, you can set up a proxy in front of your functions and operations and define a unified URL that can be passed to consuming clients. The only major drawback at the time of this session/writing this blog post is the unavailability of Authentication key as a part of the proxy calls. The reason is, because this functionality (Azure Functions Proxies is currently in Preview mode). Eventually, this feature will be made available in the future as we are actually exposing endpoints to our end users/customers.
You can watch the video of this session below.
You can give your feedback about Middleware Friday episodes, any special topic of interest, or any guest speaker whom you would like to see at Middleware Friday. Simply tweet at @MiddlewareFri or drop an email to middlewarefriday@gmail.com.
You can watch the Middleware Friday sessions here.