Call other functions inside Azure Functions

Call other functions inside Azure Functions

As some of you may know, I’m currently playing around with Azure Functions. One of the limitations I have encountered with Azure functions is the lack of first-class support for calling other functions. Fortunately, several workarounds are available to you. I will cover each of them within this post.

Azure Functions: Calling Other Functions

There is some good and bad news when it comes to calling other functions. Let’s start with the bad news first. Calling other functions from inside a function isn’t natively supported. I got this confirmed by Christopher Anderson, a Microsoft Azure project manager.

The good news is that there are several workarounds for this problem. Let’s take a closer look at the pros and cons for every possible solution. If you just want to read up on most common solution, skip to Part 4.

1 – Long function body

The simplest ‘solution’ is to include all your code within the function body. This, of course, violates all kinds of coding best practices. I’m not a fan of large functions and also dislike duplicating code. Therefore, I prefer the other options listed below. But what’s important to know, however, is that this option wont utilize additional resources. I will provide additional information on this later within this post.

2 – Helper libraries (NuGet packages)

To avoid the creation of complex functions you can use helper libraries / assemblies. The benefits are that you can easily test or reuse this code within other projects. The downside is that you’re introducing additional deployment overhead.

Fortunately, the creation of Nuget packages isn’t hard and the benefits are definitely worth it. Also important to notice is that as with the first option, code libraries wont utilize additional resources.

Note: I wrote a blogpost covering code reuse within Azure Function apps a while ago.

3 – Http Triggers

Another option to consider is an Http Trigger. Http Triggers function the same as Webhooks which you might be familiar with. Dealing with request data is simple and similar to working with the System.Net.Http namespace.

The main benefits of using Http Triggers are: Encapsulating functionality, reuse of code, not resource intensive.

Note: You can find additional information regarding Http Triggers within the Azure Functions documentation.

4 – Azure Storage Bindings

Azure Storage Triggers and Bindings is new and therefore unknown. I’ve discovered it one week ago and can say that this is a powerful addition.


By configuring a storage Trigger, you allow your function to be called on Azure Storage events. This can be any of the following storage types: Azure queue, blob or a table.

With Storage Bindings you can write data to Azure queues, blobs or tables. Different serialization restrictions are present depending on the type of binding you choose. In addition, Triggers and Bindings don’t have to be of the same storage type. For instance, you can listen for queue items and store your results within blob storage.


To solve our function call issue, you can basically use Storage Bindings and Triggers to let them communicate. The function caller returns / creates a new storage entry. This entry contains the required data for processing. At this point the function will be triggered when new entries are added.

The code and configuration below contains a simplified version of this scenario. Within the first step i’ve created a time based trigger which returns data. This data will be stored as a queue item based on the binding.

The second part contains the function which will be triggered on the creation of our new queue item.

This structure enables some interesting options. The downside are the costs involved for storage and processing items if you choose to use storage queues.

Other articles covering Azure Functions

Docs: Azure Functions triggers and bindings for Azure Storage
Blog: Azure Functions & Code Reuse
Blog: Azure Functions & Logic Apps

  • Chris Anderson [chrande@MSFT]

    One of the Azure Functions PMs here. Great post!

    One thing to consider with the Queue based approach is that you do pay a small cost per queue (it’s small), but you get better resiliency and scaling. Queue messages can be scaled to other machines, rather than having a bunch of synchronous calls on the same machine. If a queue item fails, it will be retried. HTTP is another option for getting the scaling, but you have to build in retry yourself and you pay for both the http triggered function and the time you’re waiting for that function to return the request. So Queues might actually save you money and are easier to work with.

    Shared library is probably the best option, as long as it isn’t too resource heavy. You want to use the least resources per execution.

    • Thank you for your comment Chris!

      I agree that the costs of using queues are insignificant. However, it does affect the way you structure your code, and therefore important to mention.

      For my scenario I’m actually saving money by converting worker role based queue listeners to Azure Functions. It is surprisingly easy to do all of this within Azure Functions without losing a lot of granularity. Looking at the details on how queue messages are handled within Function Apps, I’m actually wondering if coding and deploying queue listeners yourself is still worth it, especially for smaller solutions.

      Hope to see more interesting features soon.

Post Navigation