Temporal Serverless Workflow

Build Temporal workflows with Serverless Workflow
Loom
Here's a Loom video explaining the idea

Why?
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.
Architecture
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.
Goals
This project has a number of goals:
- Can a Temporal workflow be configured by a DSL?
- Should a Temporal workflow be configured by a DSL?
- 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.
Getting started
Define your workflow
Create a workflow in the Serverless Workflow
schema.
An example workflow is provided.
Start your Temporal server
This can be any flavour of Temporal (Cloud or self-hosted). To start a local
development server, run:
temporal server start-dev
Run
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
Running examples
See examples directory
Schema
Variables
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 TSW_. These can also be parsed - the variable TSW_EXAMPLE_ENVVAR
would be retrieved by adding {{ .TSW_EXAMPLE_ENVVAR }} to your schema definition.
Future developments
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):
Implementation roadmap
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.
| Feature |
State |
| Workflow Document |
β
|
| Workflow Use |
π‘ |
| Workflow Schedule |
β |
| Task Call |
π‘ |
| Task Do |
β
|
| Task Emit |
β |
| Task For |
β |
| Task Fork |
π‘ |
| Task Listen |
π‘ |
| Task Raise |
β |
| Task Run |
β |
| Task Set |
β
|
| Task Switch |
β
|
| Task Try |
β |
| Task Wait |
β
|
| Lifecycle Events |
β |
| External Resource |
β |
| Authentication |
β |
| Catalog |
β |
| Extension |
β |
| Error |
β |
| Event Consumption Strategies |
β |
| Retry |
β |
| Input |
β |
| Output |
β |
| Export |
β |
| Timeout |
β |
| Duration |
β |
| Endpoint |
β |
| HTTP Response |
β |
| HTTP Request |
β |
| URI Template |
β |
| Container Lifetime |
β |
| Process Result |
β |
| AsyncAPI Server |
β |
| AsyncAPI Outbound Message |
β |
| AsyncAPI Subscription |
β |
| Workflow Definition Reference |
β
|
| Subscription Iterator |
β |
Contributing
Open in a container
Commit style
All commits must be done in the Conventional Commit
format.
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]