What is 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.
Step 1 – Create the Function App
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.
- Log in to Azure Portal
- Click + (New) -> Compute -> Function App
- Enter the Function App name
- Choose your subscription, resource group, hosting plan, location
- Create your new Storage or choose an existing storage account
- Click Create to create the Azure Function App
Step 2 – Create a new Function
In this step, we will create a new function and define the naming conventions.
- Select App Services from the left navigation menu
- Click on the function app name that we created in the previous step
- Click the + next to Functions
- You will be presented with a Quick Start pane where you can select your preference and create the Azure Function.
In our case, we will opt for the ‘Custom Function‘ option found in the second half of the quick start pane.
- Select HTTPTrigger-CSharp from the list (for the POST trigger. We will call the trigger as Request)
- Enter the name for the function, say, Request and set the Authorization Level to Function
- Next, click the Integrate label. Here we need to define the Allowed HTTP Requests. We will select “Selected Methods” and let the function app expose only the “POST” HTTP Method.
- Click Save
- Go back to the App Services section and select the Function App that we created in Step 1 (mffunctionapp)
- In the Functions section on the left-hand side menu, click the Request tab. You can now construct the code relevant to the above-mentioned scenario. The code will look as follows –
- Repeat Steps 5–10 to create the second trigger (GET). We will call the trigger as Response.
- Copy both the function URLs from the </>Get function URL link and keep it handy
- Next, you need to enable Azure Functions Proxies (preview) in the Function App home page under Settings
- Select the + next to Proxies (preview) in the Function Apps page
- Provide the following details to create the proxy. You need to perform this step twice for the Request (POST) and Response (GET). What’s interesting here is that for both the proxies that we create, the Proxy URL will be the same.
- Enter a name for your proxy (Eg., ProxyRequest, ProxyResponse)
- Route template – Enter a common URI for both the POST and GET (Eg., api/<name>)
- Allowed HTTP methods – For the ProxyRequest (POST), choose POST check box. Similarly for ProxyResponse (GET), choose GET check box
- Backend URL – Enter the backend URL that you copied for both the GET and POST (earlier in step 12)
- Click Create to create the proxies
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.
Test 1 – Trigger a Request (POST) to publish a message into Azure Service Bus 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 ServiceBus360.
Test 2 – Trigger a Request (GET) to receive a message from Azure Service Bus Queue
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 ServiceBus360.
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.
Watch the video of this session
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 firstname.lastname@example.org.
You can watch the Middleware Friday sessions here.