Introduction to Azure Functions Proxies (Middleware Friday)

Introduction to Azure Functions Proxies (Middleware Friday)

Published on : Apr 17, 2017

Category : Events

Sriram Hariharan


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“.

You can download this article as a PDF document Download now.

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.

Demo Scenario

The high-level architectural diagram of the demo is shown below –

Microsoft Azure with power equipment

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.

  1. Log in to Azure Portal
  2. Click + (New) -> Compute -> Function App
  3. Enter the Function App name
  4. Choose your subscription, resource group, hosting plan, location
  5. Create your new Storage or choose an existing storage account
  6. Click Create to create the Azure Function App

creating azure function app

Step 2 – Create a new Function

In this step, we will create a new function and define the naming conventions.

  1. Select App Services from the left navigation menu
  2. Click on the function app name that we created in the previous step
  3. Click the + next to Functions
    creating a new azure function
  4. You will be presented with a Quick Start pane where you can select your preference and create the Azure Function.
    premade function
    In our case, we will opt for the ‘Custom Function‘ option found in the second half of the quick start pane.
  5. Select HTTPTrigger-CSharp from the list (for the POST trigger. We will call the trigger as Request)
  6. Enter the name for the function, say, Request and set the Authorization Level to Function
    function app authorization level
  7. 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.
    defining http requests
  8. Click Save
  9. Go back to the App Services section and select the Function App that we created in Step 1 (mffunctionapp)
  10. 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 –
    creating a function app
  11. You can download this article as a PDF document Download now.
  12. Repeat Steps 5–10 to create the second trigger (GET). We will call the trigger as Response.
    naming function app
    function app creation
  13. Copy both the function URLs from the </>Get function URL link and keep it handy
  14. Next, you need to enable Azure Functions Proxies (preview) in the Function App home page under Settings
    enabling Azure Functions Proxies
  15. Select the next to Proxies (preview) in the Function Apps pagefunction app screen
  16. 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.
    1. Enter a name for your proxy (Eg., ProxyRequest, ProxyResponse)
    2. Route template – Enter a common URI for both the POST and GET (Eg., api/<name>)
    3. Allowed HTTP methods – For the ProxyRequest (POST), choose POST check box. Similarly for ProxyResponse (GET), choose GET check box
    4. Backend URL – Enter the backend URL that you copied for both the GET and POST (earlier in step 12)
    5. Click Create to create the proxies
      selecting http method
      http method - post

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.

triggering a request

triggering a request

Now let’s see if the request is available in the Service Bus Queue using Serverlesss360.

receive messages from queue

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.

request to receive a message

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.

retrieving messages from queue


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

You can watch the Middleware Friday sessions here.

You can download this article as a PDF document Download now.