Azure Functions is a serverless computing framework that simplifies the development of event-driven applications, while Dapr is a microservices framework that provides a set of building blocks for building distributed systems.
The Azure Functions programming model uses a declarative approach, where developers define the triggers and bindings for their functions in a configuration file or through the Azure portal. The Dapr programming model is more flexible, allowing developers to use any programming language, framework, or infrastructure of their choice.
Converging the strengths of both programming models, Azure Functions Dapr extension allows you to easily interact with the Dapr APIs from an Azure Function using triggers and bindings. This extension works with Azure Functions on Azure Container Apps, Local Dev & Azure Kubernetes. This extension provides integration to Dapr state, secrets, pub-sub, and bindings directly in your function code. Extension is modularized into 6 components.
-
Extension runtime: The extension includes a runtime that initializes the Dapr and sets up the necessary environment variables and configuration. It also provides a set of APIs and bindings that the function can use to interact with Dapr.
-
Configuration: The extension requires configuration settings to be set up properly to interact with Dapr's APIs. These settings include the Dapr HTTP endpoint, Dapr app ID, and Dapr API token.
-
Trigger bindings: The extension provides trigger bindings that enable functions to be triggered by Dapr events such as service-to-service requests and pub/sub events. This allows functions to react to events and perform actions based on them.
-
Input bindings: The extension provides input bindings that allow functions to receive data from Dapr, such as state values or input from external systems. This allows functions to consume data from other systems and use it in their processing.
-
Output bindings: The extension provides output bindings that allow functions to send data to Dapr or external systems, such as publishing events or sending HTTP requests. This allows functions to produce output that can be consumed by other systems.
-
Dapr API integration: The Dapr extension for functions integrates with Dapr's HTTP API to perform operations such as saving state, publishing events, and invoking service-to-service requests. This integration is handled by the Dapr implicit. Extension provides both HTTP client & HTTP Server (Kestrel) to interact with Dapr's APIs. These are built on top of the Dapr SDK and provide a consistent interface for making HTTP requests.
This extension supports all the languages that Azure Function supports :
You can easily deploy Azure Functions with the Dapr extension in Azure Container Apps (ACA), self-hosted mode or Kubernetes. Follow the below quickstarts guides to deploy Azure Functions with Dapr Extension.
If you are new to Azure Functions, it's recommended to try out an Azure Function's quickstart first to understand the basics of the programming model.
You can run through a quickstart of developing JavaScript Azure Functions that leverage Dapr following this tutorial
Azure Function triggers cause a function to run. A trigger defines how a function is invoked and a function must have exactly one trigger. Triggers have associated data, which is often provided as the payload of the function.
| Trigger Type | Description | Code Samples |
|---|---|---|
| daprBindingTrigger | Trigger on a Dapr input binding | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprServiceInvocationTrigger | Trigger on a Dapr service invocation | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprTopicTrigger | Trigger on a Dapr topic subscription | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
Azure Function bindings is a way of declaratively connecting another resource to the function; bindings may be connected as Input Bindings, Output Bindings, or both. Data from bindings is provided to the function as parameters.
| Binding Type | Direction | Description | Code Samples |
|---|---|---|---|
| daprState | Input | Pull in Dapr state for an execution | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprSecret | Input | Pull in Dapr secrets for an execution | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprState | Output | Save a value to Dapr state | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprInvoke | Output | Invoke another Dapr app | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprPublish | Output | Publish a message to a Dapr topic | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
| daprBinding | Output | Send a value to a Dapr output binding | C# Isolated, C# Inproc, JavaScript, Python V2, Python V1, Java, PowerShell |
When you are triggering a function from Dapr, the extension will expose port 3001 automatically to listen to incoming requests from the Dapr sidecar. This port is configurable, you can provide any other available port in your app settings for DAPR_APP_PORT env variable instead of 3001.
IMPORTANT: Port 3001 will only be exposed and listened if a Dapr trigger is defined in the function app. When using Dapr the sidecar will wait to receive a response from the defined port before completing instantiation. This means it is important to NOT define the
dapr.io/app-portannotation or--app-portunless you have a trigger. Doing so may lock your application from the Dapr sidecar. Port 3001 does not need to be exposed or defined if only using input and output bindings.
By default, when Azure Functions tries to communicate with Dapr it will call Dapr over the port resolved from the environment variable DAPR_HTTP_PORT. If that is null, it will default 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 will use http://localhost:{DAPR_HTTP_PORT}.
The function app will still expose another port and endpoint for things like HTTP triggers (locally this defaults to 7071, in a container it defaults to 80).
- By Design: In isolated mode, there's no support for using POCO (Plain Old CLR Object) models in output bindings and triggers. All payloads must be sent as JSON data, and these data should be treated as the JsonElement type in Azure Functions. You can refer to the input bindings, output bindings, and triggers sections to understand the data format and the necessary properties for each type of binding.