Azure Functions proxy - overview

Azure Functions are great for building a bigger solution, which contains smaller services representing logical separation of different responsibilities. There's however a problem if you'd like to encapsulate logic what can be accessed and which HTTP methods are allowed. Additional problem arises if you're going to somehow avoid passing function keys to each application consuming or using your function. Fortunately Microsoft has just published a public preview of Azure Functions proxy - a very simple yet powerful concept, which allows you to overcome mentioned problems and make your functions to even more fun to work with.

Special thanks to @marekgrabarz for making me aware of this feature and encouraging to write some words about it.

Hide your functions

Actually to take advantage of this feature there's one requirement - a Function app. If you don't have one, quickly go to Azure Portal and create one!

Once you have your Function app created, simply click on it. You will see a Function app screen with a new feature added:

as you can see it's still in preview so it may be still a bit unstable, but it won't bother us in this moment. To be actually able to use proxies, you have to enable them. Go to the Function app settings and turn proxies on in the Proxies(preview) section. Now we can do some real work!

Create a simple function, for which we'll create a proxy. For the testing scenario I created a following function:

using System.Net;

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
    return req.CreateResponse(HttpStatusCode.OK, "You called ProxiedFunction1!");

now with a function created, we can create a proxy for it. To do so, follow below steps:

  1. Click on the New proxy button
  2. Give it an unique name and template(I used proxy/function1)
  3. For Backend URL you have to use any URL you'd like to forward a request to(in my case it was my function Function URL with the key)
  4. Simply click a Create button

Now try to access your proxy by going to https://{your_function_app){template} - if you used the same function as me, you'll get "You called ProxiedFunction1!" as a response. You can create as many proxies as you want and connect them to the resource of your choice(it can be a function, a web app or other endpoint accessible with HTTP). Your possibilities are unlimited here.

Parameters and application settings

You can also create a proxy in more generic way simply using parameter in your route. Consider following example:

Whatever you pass as a {function} parameter, it will be routed to the ProxiedFunction1 function

Additionally you can reference application settings what can be helpful if you're searching for more flexibility. Let's create another proxy like this:

What is more, I added MY_SECRET key with a value of a5gYhj87Hgsta to the app settings. How when I try to access proxy, I can go to and get desired results. If a secret doesn't match, you'll get HTTP 404 instead.


Currently alternative to this kind of proxy is using Application Gateway or API Management. The advantage of this solution is its simplicity and cost related - since Azure Functions are free for the first 1M requests*, it's possible that in the beginning you will be running this solution for free.


Currently proxies for Azure Functions are limited in functionality by the preview version. Fortunately the team responsible for this component promised many enhancements implemented soon - can't wait to test them :)

* considering duplicated request when a proxy rewrites it, depending on how proxy is treated in pricing, it can be lowered to 0.5M free requests

Building feature branches on VSTS automatically

Currently VSTS lacks(see edit below) really handy feature, which lets you trigger a build based on a branch wildcard. For instance, I'd like to run my build definition only for refs/heads/feature/* branches. While it's super-easy when using e.g. TeamCity, with VSTS it requires us to prepare a smart workaround.

Service hooks

VSTS provides us a wide collection of different service hooks. They can be used to command builds, analyze logs or trigger any kind of an event. In fact the list of available services is already impressing and gets bigger - I strongly recommend you to take a look when you have a minute.

Besides integrating with third-party services like Slack, Bamboo or Trello, it allows us to use a simple Web Hook, which can send a specific event to a specific endpoint. Because we can send any event to any endpoint, the sky is the only limit - you can create a "lambda" using Azure Function(like me), a simple WebAPI or old but still reliable MVC application using technology stack of your choice. Whatever solution you'll create, it will work as long as it can process HTTP requests.

Kick it back!

Retrieving an event from VSTS is cool but gives information only. What we really need is to orchestrate VSTS to schedule a build using a specific build definition on a specific branch. Once again REST API provided by VSTS comes to the rescue:

POST https://{instance}/DefaultCollection/{project}/_apis/build/builds?api-version={version}

The important part of this request is its body:

  "definition": {
    "id": 25
  "sourceBranch": "refs/heads/master",
  "parameters": "{\"system.debug\":\"true\",\"BuildConfiguration\":\"debug\",\"BuildPlatform\":\"x64\"}"

There're two things which are required to make it work: build definition ID and source branch. You can obtain the former from the URL when you go directly to the definition you choose, once the latter is being passed along with the whole request in data.resource.refUpdates[0].name field.

Code example

An example of a Azure Function which can handle the functionality:

public static async Task<HttpResponseMessage> Run(HttpRequestMessage req, TraceWriter log)
    log.Info("C# HTTP trigger function processed a request.");

    // Get request body
    dynamic data = await req.Content.ReadAsAsync<object>();

    if(data.eventType == "git.push" && data.resource.refUpdates[0].name.Value.Contains("refs/heads/feature")) {
        using(var client = new HttpClient()) {
            var branch = data.resource.refUpdates[0].name.Value;
            log.Info($"Build will be scheduled for {branch} branch.");

            client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", "yourToken");
            await client.PostAsync("https://{yourInstance}{projectId}/_apis/build/builds?api-version=2.0", 
                new StringContent($"{{\"definition\": {{\"id\": {definitionId}},\"sourceBranch\": \"{branch}\"", Encoding.UTF8, "application/json"));

            log.Info($"Build scheduled successfully!.");
            return req.CreateResponse(HttpStatusCode.OK, "Build scheduled");

    return req.CreateResponse(HttpStatusCode.BadRequest, "Error occured");

Combining it all

To summarize steps needed here:

  1. Go to Service Hooks tab in VSTS and create new Web Hook pointing to your service endpoint using Code pushed as event
  2. Create a service, which will handle requests sent by VSTS and call its API to schedule a build
  3. Enjoy builds including only filtered branches


After this was pointed I checked recently updated docs and it seems wildcard are now officially supported! You can treat this post as an inspiration for building new features around VSTS. You can find new documentation here ->