Dapr Extension for Azure Functions

Article
05/10/2024

The Dapr Extension for Azure Functions is a set of tools and services that allow developers to easily integrate Azure Functions with the Distributed Application Runtime (Dapr) platform.

Azure Functions is an event-driven compute service that provides a set of triggers and bindings to easily connect with other Azure services. Dapr provides a set of building blocks and best practices for building distributed applications, including microservices, state management, pub/sub messaging, and more.

With the integration between Dapr and Functions, you can build functions that react to events from Dapr or external systems.

Action	Direction	Type
Trigger on a Dapr input binding	N/A	daprBindingTrigger
Trigger on a Dapr service invocation	N/A	daprServiceInvocationTrigger
Trigger on a Dapr topic subscription	N/A	daprTopicTrigger
Pull in Dapr state for an execution	In	daprState
Pull in Dapr secrets for an execution	In	daprSecret
Save a value to a Dapr state	Out	daprState
Invoke another Dapr app	Out	daprInvoke
Publish a message to a Dapr topic	Out	daprPublish
Send a value to a Dapr output binding	Out	daprBinding

Install extension

The extension NuGet package you install depends on the C# mode in-process or isolated worker process you're using in your function app:

In-process
Isolated process

This extension is available by installing the NuGet package, version 1.0.0.

Using the .NET CLI:

dotnet add package Microsoft.Azure.WebJobs.Extensions.Dapr

Add the extension to your project by installing the NuGet package, version 1.0.0.

Using the .NET CLI:

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Dapr

Install bundle

Bundle v4.x

You can add the extension by adding or replacing the following code in your host.json file:

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 5.0.0)"
  }
}

Dapr enablement

You can configure Dapr using various [arguments and annotations][dapr-args] based on the runtime context. You can configure Dapr for Azure Functions through two channels:

Infrastructure as Code (IaC) templates, as in Bicep or Azure Resource Manager (ARM) templates
The Azure portal

When using an IaC template, specify the following arguments in the properties section of the container app resource definition.

Bicep
ARM

DaprConfig: {
  enabled: true
  appId: '${envResourceNamePrefix}-funcapp'
  appPort: 3001
  httpReadBufferSize: ''
  httpMaxRequestSize: ''
  logLevel: ''
  enableApiLogging: true
}

"DaprConfig": {
  "enabled": true,
  "appId": "${envResourceNamePrefix}-funcapp",
  "appPort": 3001,
  "httpReadBufferSize": "",
  "httpMaxRequestSize": "",
  "logLevel": "",
  "enableApiLogging": true
}

The above Dapr configuration values are considered application-scope changes. When you run a container app in multiple-revision mode, changes to these settings won't create a new revision. Instead, all existing revisions are restarted to ensure they're configured with the most up-to-date values.

When configuring Dapr using the Azure portal, navigate to your function app and select Dapr from the left-side menu:

Screenshot demonstrating where to find Dapr enablement for a Function App in the Azure portal.

Dapr ports and listeners

When you're triggering a function from Dapr, the extension exposes port 3001 automatically to listen to incoming requests from the Dapr sidecar.

Important

Port 3001 is only exposed and listened to if a Dapr trigger is defined in the function app. When using Dapr, the sidecar waits to receive a response from the defined port before completing instantiation. Do not define the dapr.io/port annotation or --app-port unless you have a trigger. Doing so may lock your application from the Dapr sidecar.

If you're only using input and output bindings, port 3001 doesn't need to be exposed or defined.

By default, when Azure Functions tries to communicate with Dapr, it calls Dapr over the port resolved from the environment variable DAPR_HTTP_PORT. If that variable is null, it defaults to port 3500.

You can override the Dapr address used by input and output bindings by setting the DaprAddress property in the function.json for the binding (or the attribute). By default, it uses http://localhost:{DAPR_HTTP_PORT}.

The function app still exposes another port and endpoint for things like HTTP triggers, which locally defaults to 7071, but in a container, defaults to 80.

Binding types

The binding types supported for .NET depend on both the extension version and C# execution mode, which can be one of the following:

In-process class library
Isolated process

An in-process class library is a compiled C# function runs in the same process as the Functions runtime.

The Dapr Extension supports parameter types according to the table below.

Binding	Parameter types
Dapr trigger	daprBindingTrigger daprServiceInvocationTrigger daprTopicTrigger
Dapr input	daprState daprSecret
Dapr output	daprState daprInvoke daprPublish daprBinding

For examples using these types, see the GitHub repository for the extension.