Durable Function Apps Series: Intro

This is the first page to consolidate the to Azure Durable Functions series, which will focus on Node function apps with some examples in TypeScript and it will assume an understanding of Azure Function Apps v2 and certain bindings and triggers.

Series Links

Durable Functions: Series Intro Durable Functions: Function Chaining Durable Functions: Fan In/Out - (coming soon)

Intro

Durable Functions are an extension of Function Apps with the benefit, among others, of stateful operation. Stateful operation improves regular Function Apps use where state doesn't exist on a function execution as it is only aware of its own operation. While there are new concepts beyond stateful operation when it comes to durable functions, something to be considerate of is that they rely on Storage Accounts, specifically Tables and Queues, for managing state. This additional requirement can introduce increased operational cost for you or your team as the Functions are executed and the complexity increases. Another important change is that there are now types of Functions.

Activity Functions Starting with the simplest type, Activities is the basic worker for any Durable Function and are equivalent to regular functions, bound to the same restrictions and considerations. Activity Functions can have the normal output bindings, but only have a single input:

{
    "name": "$name",
    "type": "activityTrigger",
    "direction": "in"
}

Client Functions Clients are the entry point for starting any Durable Function execution flow where previously a function could be executed by any available trigger binding, but client functions can be treated as though they are regular functions like activities and are not bound to limitations of the other types of functions. The addition for clients is that they manage starting work for Orchestrations and Entities, but placing a message on the Storage Account Queue.

{
      "name": "starter",
      "type": "orchestrationClient",
      "direction": "in"
}

Entity Functions Entities are the newest addition to the Durable Extension and an addition tool to manage different components of state beyond what exists with the other Function types. They can be executed from Orchestrations and Clients and manage state explicitly by passing operation names and parameters.

{
      "name": "context",
      "type": "entityTrigger",
      "direction": "in"
}

Orchestrator Functions Orchestrators are the primary tool for state management and will likely be the most heavily used component of the Durable Extension. As a consequence of being the primary tool, have the most constraints to consider when designing & developing; as a general rule anything that can return a variable response, like async operations, API requests, or getting the current time with moment all must be avoided in an orchestrator. The constraints on will be covered in more detail in a future post, but it is part of the architecture of the stateful operation that necessitates them.

{
      "name": "context",
      "type": "orchestrationTrigger",
      "direction": "in"
}

Beyond Function Types

Outside of the new Function types there are design patterns like Fan-in/Fan-out, waiting for external events, or eternal orchestration, but there is also a number of other topics to consider like performance, scale, or instance management. Over the next few entries, we'll start to cover some basics of durable functions, examples of basic design patterns, and adding additional functional requirements can be adapted on top of them. I will also start more linking directly to existing documentation, there has been significant improvements in the last six months that really makes development easier and quicker.