Build Temporal workflows from YAML

• Loom
• Why?
• Architecture
  • Goals
• Getting started
  • Define your workflow
  • Start your Temporal server
  • Run
    • Running examples
• Schema
  • Variables
• Future developments
  • Implementation roadmap
• Contributing
  • Open in a container
  • Commit style

Here's a Loom video explaining the idea

We regularly get asked about using a domain-specific language (DSL) to make Temporal workflows in a no/low-code format. For very good reasons, this is outside the scope of the Temporal project. But still they come.

Serverless Workflow is a CNCF-sponsored project to create a vendor-neutral method of defining a workflow.

This application is designed to replace the Temporal worker by generating the workflows and activities defined. This will be a long-running application.

Triggering workflows defined by this application will be done in the normal Temporal way - see examples for more information.

Conceptually, the items in the do array of the schema are things that a Temporal workflow can do. Sometimes these will be invoked by the workflow, but most will be activities.

This project has a number of goals:

1. Can a Temporal workflow be configured by a DSL?
2. Should a Temporal workflow be configured by a DSL?
3. Would this be a useful addition to the Temporal ecosystem?

From a deployment point of view, this is designed as a standalone application. This allows for it to be run in multiple different ways, such as in Kubernetes or on bare metal.

Create a workflow in the Serverless Workflow schema.

An example workflow is provided.

This can be any flavour of Temporal (Cloud or self-hosted). To start a local development server, run:

temporal server start-dev

There are many options available so it's best to look at the available options in the application's help.

go run . -h

At it's simplest, this will be:

go run . --temporal-address localhost:7233 --files ./workflow.example.yaml

It's now ready for all your workflow needs

See examples directory

Each call receives the input and output from previous calls, so that can be used in calls. This is done using the Go template variable methods - if you set an userId variable, this can be retrieved by adding {{ .userId }} in your schema definition.

Environment variables are also used, provided that the match the prefix - by default, this is TDSL_. These can also be parsed - the variable TDSL_EXAMPLE_ENVVAR would be retrieved by adding {{ .TDSL_EXAMPLE_ENVVAR }} to your schema definition.

This is largely dependent upon how much interest there in the community, so please add stars and raise pull requests.

This is a very basic implementation, with only support for the basic Temporal workflow. Things that will be needed to make this a production-grade system (not exhaustive):

• Temporal worker versioning
• Custom tasks, especially to call user-defined activities
• Published release/Helm chart

The table below lists the current state of this implementation. This table is a roadmap for the project based on the DSL Reference doc.

This project currently only supports DSL 1.0.0.

• Open in a container

All commits must be done in the Conventional Commit format.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]