Azure Functions developers guide

• 10/12/2017
• 6 minutes to read
• Contributors
  • 
  • 
  • 
  • 
  • 
  • all

In Azure Functions, specific functions share a few core technical concepts and components, regardless of the language or binding you use. Before you jump into learning details specific to a given language or binding, be sure to read through this overview that applies to all of them.

This article assumes that you've already read the Azure Functions overview and are familiar with WebJobs SDK concepts such as triggers, bindings, and the JobHost runtime. Azure Functions is based on the WebJobs SDK.

Function code

A function is the primary concept in Azure Functions. You write code for a function in a language of your choice and save the code and configuration files in the same folder. The configuration is named function.json, which contains JSON configuration data. Various languages are supported, and each one has a slightly different experience optimized to work best for that language.

The function.json file defines the function bindings and other configuration settings. The runtime uses this file to determine the events to monitor and how to pass data into and return data from function execution. The following is an example function.json file.

{
    "disabled":false,
    "bindings":[
        // ... bindings here
        {
            "type": "bindingType",
            "direction": "in",
            "name": "myParamName",
            // ... more depending on binding
        }
    ]
}

Set the disabled property to true to prevent the function from being executed.

The bindings property is where you configure both triggers and bindings. Each binding shares a few common settings and some settings, which are specific to a particular type of binding. Every binding requires the following settings:

Function app

A function app provides an execution context in Azure in which your functions run. A function app is comprised of one or more individual functions that are managed together by Azure App Service. All of the functions in a function app share the same pricing plan, continuous deployment and runtime version. Think of a function app as a way to organize and collectively manage your functions.

Runtime

The Azure Functions runtime, or script host, is the underlying host that listens for events, gathers and sends data, and ultimately runs your code. This same host is used by the WebJobs SDK.

There is also a web host that handles HTTP trigger requests for the runtime. Having two hosts helps to isolate the runtime from the front end traffic managed by the web host.

Folder structure

The code for all the functions in a specific function app is located in a root project folder that contains a host configuration file and one or more subfolders. Each subfolder contains the code for a separate function, as in the following representation:

FunctionApp
 | - host.json
 | - Myfirstfunction
 | | - function.json
 | | - ...  
 | - mysecondfunction
 | | - function.json
 | | - ...  
 | - SharedCode
 | - bin

In version 2.x of the Functions runtime, all functions in the function app must share the same language worker.

The host.json file, which contains some runtime-specific configurations, is in the root folder of the function app. A bin folder contains packages and other library files required by the function app. See the language-specific requirements for a function app project:

• C# class library (.csproj)
• C# script (.csx)
• F# script
• Java
• JavaScript

When setting-up a project for deploying functions to a function app in Azure, you can treat this folder structure as your site code. We recommend using package deployment to deploy your project to your function app in Azure. You can also use existing tools like continuous integration and deployment and Azure DevOps.

How to update function app files

The function editor built into the Azure portal lets you update the function.json file and the code file for a function. To upload or update other files such as package.json or project.json or dependencies, you have to use other deployment methods.

Function apps are built on App Service, so all the deployment options available to standard web apps are also available for function apps. Here are some methods you can use to upload or update function app files.

Use local tools and publishing

Function apps can be authored and published using various tools, including Visual Studio, Visual Studio Code, IntelliJ, Eclipse, and the Azure Functions Core Tools. For more information, see Code and test Azure Functions locally.

Continuous deployment

Follow the instructions in the topic Continuous deployment for Azure Functions.

Parallel execution

When multiple triggering events occur faster than a single-threaded function runtime can process them, the runtime may invoke the function multiple times in parallel. If a function app is using the Consumption hosting plan, the function app could scale out automatically. Each instance of the function app, whether the app runs on the Consumption hosting plan or a regular App Service hosting plan, might process concurrent function invocations in parallel using multiple threads. The maximum number of concurrent function invocations in each function app instance varies based on the type of trigger being used as well as the resources used by other functions within the function app.

Functions runtime versioning

You can configure the version of the Functions runtime using the FUNCTIONS_EXTENSION_VERSION app setting. For example, the value "~2" indicates that your Function App will use 2.x as its major version. Function Apps are upgraded to each new minor version as they are released. For more information, including how to view the exact version of your function app, see How to target Azure Functions runtime versions.

Repositories

The code for Azure Functions is open source and stored in GitHub repositories:

• Azure Functions runtime
• Azure Functions portal
• Azure Functions templates
• Azure WebJobs SDK
• Azure WebJobs SDK Extensions

Bindings

Here is a table of all supported bindings.

The following table shows the bindings that are supported in the two major versions of the Azure Functions runtime.

¹ In 2.x, all bindings except HTTP and Timer must be registered. See Register binding extensions.

² Experimental — not supported and might be abandoned in the future.

Having issues with errors coming from the bindings? Review the Azure Functions Binding Error Codes documentation.

Reporting Issues

Next steps

For more information, see the following resources:

• Best Practices for Azure Functions
• Azure Functions C# developer reference
• Azure Functions F# developer reference
• Azure Functions NodeJS developer reference
• Azure Functions triggers and bindings
• Azure Functions: The Journey on the Azure App Service team blog. A history of how Azure Functions was developed.