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 of every possible solution. If you just want to read up on the most common solution, skip to Part 4.
1 – Long function body
The simplest’ solution’ is to include all your code within the function body. However violates all kinds of coding best practices. Therefore, I prefer the other options listed below. But what’s important to know, however, is that this option won’t utilize additional resources. I will provide further 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 quickly 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 worth it. Important to notice is that as with the first option, code libraries won’t 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. Also, 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 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. The 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 exciting options. The downside is 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