Examples
Seven examples. Five are each written for Temporal, for AWS and for pydantic-graph: the same flow,
with its tasks called and its news brought in the way the platform does. Temporal is dandori's main
platform, and its version is the one to read first. The other two, invoice and payout, are written
once and run as they are on every platform. The version for Temporal, invoice and payout are also
drawn by dandori doc, on a page where each scenario lights up the way its run goes
(Draw a workflow).
Every version has a Japanese twin beside it, <name>.ja.flow (fulfillment's child too,
arrange_delivery.ja.flow), which names everything in Japanese but what an API description fixes:
Stripe's fields and states, the warehouse's .proto, the SNS and SQS APIs. The Japanese versions of
fulfillment implement a service of their own, fulfillment.ja.proto, whose names in JSON are
Japanese. So does payout's bank, payout.ja.proto. The Japanese rules sit beside the English ones
in each rules/, and the Japanese site draws the Japanese versions.
| Example | For Temporal | For AWS (Step Functions, Lambda durable functions) | For pydantic-graph | Drawn |
|---|---|---|---|---|
| a hotel booking that holds a card and captures at check-out, held to Stripe's OpenAPI document | temporal | aws | pydantic-graph | page |
| an order in a warehouse's system, reminded, shipped, delivered | temporal | aws | pydantic-graph | page |
reserving the lines of an order side by side, packing, delivery: a workflow that implements a service of a .proto (Implement a service), the warehouse called by Connect, with the types of its answers made from its .proto, and the delivery a child flow, arrange_delivery, written once for every platform |
temporal | aws | pydantic-graph | page |
| an inquiry sorted by Jev, with an agent's reading when Jev is not sure, a rule that routes it, and an agent that drafts the reply | temporal | aws | pydantic-graph | page |
| an application scored by Jev, and a rule that weighs how sure the score is and sends the rest to a person's approval; also for Argo Workflows | temporal | aws (Lambda durable functions) | pydantic-graph | page |
| an order's goods held in stock until its payment is due, then shipped once paid or put back: the stock a book of chobo's, the due date a date of koyomi's (Dates and books) | invoice, the same for every platform | the same | the same | page |
a payout to a seller: the bank's API pays the account by its id, and a model drafts the notice; the bank's .proto marks the account's number and holder secret, and the flow carries neither, so no check of secrets says anything |
payout, the same for every platform | the same | the same | page |
How the versions differ
For Temporal, a call to an HTTP API is an activity dandori writes (the Transport adds the
credentials, so there is no connection), and the rest are activities you write. News from outside
the workflow comes as an event, sent to the workflow by its id (Stripe's webhook in hotel, the
carrier in order); a request that is answered later stays a callback, answered by the Update the
generated client sends. Hotel and order release what they hold when the workflow is cancelled
(on cancel); fulfillment and review send work to other task queues, and fulfillment falls back to
the standard carrier when its child flow finds no next-day van (the child's fail NoVan, which the
task declares). Inquiry calls its rule as a local activity, and order's reminder loop goes on in a
new run as its history grows. Review asks Jev from the workers of its own task queue, and inquiry
from the workflow's.
For AWS, the tasks call Lambda functions, HTTP APIs through EventBridge connections, and SNS and SQS, as Step Functions does; a callback hands on a task token. Order calls its urgency rule at its Connect service, through a connection too, where the other versions keep the rule's code with the workflow (A rule as a service). Lambda durable functions runs the same versions, and the code dandori writes for the other platforms makes the same calls, so these build for all five. Jev is called by an HTTP Task, with TypeSafe's key in the connection. Review's is the exception: asking for the approval and the notice are your own code, which Step Functions cannot run, so on AWS it is for Lambda durable functions alone.
For Argo Workflows, review's approval and notice are containers of your images (image), and
its scoring and rule run in the caller image dandori builds. The other examples run on Argo as they
are written for AWS, with their calls made by that caller image.
For pydantic-graph, the graph runs in the Python process that takes the input: a call to an HTTP
API, an agent or Jev is a function dandori writes, the rules run in the process, the rest are functions
you write, and a callback is answered in the same process (Deps.callbacks). Waits hold the process,
and a run the process loses is lost.
Only a flow that runs as it is on every platform sits beside the versions: fulfillment's child, whose
calls are HTTP ones dandori writes for each. The versions share the rules (rules/) and the API
descriptions (specs/). Invoice has no versions: its calls are an HTTP API, a date and a book's
operations, which dandori writes for every platform, so the one flow sits in its directory with the
dates file, its calendar and the book (dates/, calendars/, books/).
The tests' flows
The flows under
tests/flows exercise the corners of the
language: lists put into json, a parallel loop inside a parallel loop, agents' answers with every
kind of type, Jev's questions of every kind and how sure its answers are, calls that time out, local
rules, Connect's zero values, events, services implemented, whose requests come with their zero
values left out, and dates and books (two dates of one file called as local activities, now, a
transfer done at once, and a hold posted in part). They are written with
Japanese names on purpose, to see that names outside ASCII come through all five platforms as
identifiers, keys and URL paths.