Skip to content

Commit

Permalink
Merge pull request dapr#4028 from ASHIQUEMD/wfbackend-docs
Browse files Browse the repository at this point in the history
Add workflow backend documentation
  • Loading branch information
hhunter-ms authored Feb 14, 2024
2 parents 90bbf6f + ae90b50 commit 020324e
Show file tree
Hide file tree
Showing 4 changed files with 65 additions and 0 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@ Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-v
- The architecture of the Dapr Workflow engine
- How the workflow engine interacts with application code
- How the workflow engine fits into the overall Dapr architecture
- How different workflow backends can work with workflow engine

For more information on how to author Dapr Workflows in your application, see [How to: Author a workflow]({{< ref "workflow-overview.md" >}}).

Expand Down Expand Up @@ -173,6 +174,24 @@ Also, the Dapr Workflow engine requires that all instances of each workflow app

Workflows don't control the specifics of how load is distributed across the cluster. For example, if a workflow schedules 10 activity tasks to run in parallel, all 10 tasks may run on as many as 10 different compute nodes or as few as a single compute node. The actual scale behavior is determined by the actor placement service, which manages the distribution of the actors that represent each of the workflow's tasks.

## Workflow backend

The workflow backend is responsible for orchestrating and preserving the state of workflows. At any given time, only one backend can be supported. You can configure the workflow backend as a component, similar to any other component in Dapr. Configuration requires:
1. Specifying the type of workflow backend.
1. Providing the configuration specific to that backend.

For instance, the following sample demonstrates how to define a actor backend component. Dapr workflow currently supports only the actor backend by default, and users are not required to define an actor backend component to use it.

```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: actorbackend
spec:
type: workflowbackend.actor
version: v1
```
## Workflow latency
In order to provide guarantees around durability and resiliency, Dapr Workflows frequently write to the state store and rely on reminders to drive execution. Dapr Workflows therefore may not be appropriate for latency-sensitive workloads. Expected sources of high latency include:
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -147,6 +147,18 @@ Workflows can also wait for multiple external event signals of the same name, in

Learn more about [external system interaction.]({{< ref "workflow-patterns.md#external-system-interaction" >}})

## Workflow backend

Dapr Workflow relies on the Durable Task Framework for Go (a.k.a. [durabletask-go](https://github.com/microsoft/durabletask-go)) as the core engine for executing workflows. This engine is designed to support multiple backend implementations. For example, the [durabletask-go](https://github.com/microsoft/durabletask-go) repo includes a SQLite implementation and the Dapr repo includes an Actors implementation.

By default, Dapr Workflow supports the Actors backend, which is stable and scalable. However, you can choose a different backend supported in Dapr Workflow. For example, [SQLite](https://github.com/microsoft/durabletask-go/tree/main/backend/sqlite)(TBD future release) could be an option for backend for local development and testing.

The backend implementation is largely decoupled from the workflow core engine or the programming model that you see. The backend primarily impacts:
- How workflow state is stored
- How workflow execution is coordinated across replicas

In that sense, it's similar to Dapr's state store abstraction, except designed specifically for workflow. All APIs and programming model features are the same, regardless of which backend is used.

## Limitations

### Workflow determinism and code restraints
Expand Down
Original file line number Diff line number Diff line change
@@ -0,0 +1,10 @@
---
type: docs
title: "Workflow backend component specs"
linkTitle: "Workflow backend"
weight: 9000
description: The supported workflow backend that orchestrate workflow and save workflow state
no_list: true
---

{{< partial "components/description.html" >}}
Original file line number Diff line number Diff line change
@@ -0,0 +1,24 @@
---
type: docs
title: "Actor workflow backend"
linkTitle: "Actor workflow backend"
description: Detailed information on the Actor workflow backend component
---

## Component format

The Actor workflow backend is the default backend in Dapr. If no workflow backend is explicitly defined, the Actor backend will be used automatically.

You don't need to define any components to use the Actor workflow backend. It's ready to use out-of-the-box.

However, if you wish to explicitly define the Actor workflow backend as a component, you can do so, as shown in the example below.

```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: actorbackend
spec:
type: workflowbackend.actor
version: v1
```

0 comments on commit 020324e

Please sign in to comment.