Even when you’re dealing with Function Apps that have limited scope it’s a good idea to break your scripts up into manageable, possibly reusable chunks. This is especially true if you want to work with the same data in several Functions in your app.
This is one way you can organize your scripts, types and objects in Azure Function Apps, and we’ll have a deeper look at another approach later in this series.
This article is part of an ongoing series on Azure Functions.
The automatic bindings in Azure Functions are pretty nifty and cut out a lot of the communication and serialization cruft you might otherwise have to deal with. You’ll see function signatures like the following:
Stream is not a value type, it’s a reference type…a complex object that is hydrated by the runtime for you. These parameters are bound for you when the function is executed and values from the input - be it a new file created on a file commit in blob storage, an HTTP request or some other trigger - will be mapped into the types you provide in your method signature. You can think of this as model binding as we know it in ASP.NET MVC (if you’re from that background).
There is a step in the creation of your Function where you create the mappning for these bindings, and different types of Functions seem to have different capabilities for binding. For example, your input bindings for Queues seems to be more powerful (can bind to POCOs) whereas the HTTP-triggered Functions seem to only allow for the HTTPReqeust binding, meaning you’ll have to deserialize the payload yourself.
The first thing you’ll want to do is to not put your types in your scripts, unless it’s truly a single-purpose Function. In the code editor you can reveal your project assets by clicking the View Files button.
In the bottom of that tool pane, click the add button and create a new file. Here, my
person.csx script has a class definition in it.
When you define types in other files you will need to pull them into your Function, they are not inherantly available. You can pull in a type in another script as you would pull in a reference to an assembly:
This allows you use the type either as a binding parameter (if supported for your Function trigger type) or as an instance you create in code. Here’s an of using the
Person class in an HTTP-triggered Function:
Now, should you pass in a payload on an HTTP request with a JSON body of something like the following, your Function will be able to read that data out with
Even though there is a default set of namespaces available to you in your Function scripts, I think it is advisable to explicitly declare your
using statements. This will prevent problems with namespace conflicts, make it more apparent to others where your types are coming from (including future you, who tends to disapprove of older-you’s shortcuts), and make it easier if you want to move your types out of the cloud and into reusable libraries.
Here are some things to try out:
- Create a type in its own file in the Function Apps portal
- Reference the type in another script and use the type in your Function
- Try invoking the Function with Postman or another tool that lets you send HTTP requests
- Day 1: How to organize types in your Azure Function scripts
- Day 2: How to resize an image uploaded to Azure Blog Storage
- Day 3: How to "fan out" work so your Functions can scale
- Day 4: How to deploy to Azure Functions using GitHub
- Day 4.5: Writing Azure Functions in F# Guest Post by Simon Timms
- Day 5: How to import third-party libraries (Up Next!)