This is the next article in the series On the Way to Step Functions - you will find the other articles linked below: On the way to step functions: Part 1 On the way to step functions: Part 2 We have highlighted that DAGs are actually the underpinning of any workflow/durable computation engine (barring serializable continuations). I would like to highlight another aspect of that reality: that there are two worlds. TL;DR - if you are a Rails user and that topic interests you, skip away to geneva_drive which is pretty much how I feel we “should do it” in Rails-land.

The RubyLA blog offers insights, tutorials, and community updates for Ruby developers in Los Angeles and beyond. Developers can explore Ruby language features, web development frameworks, and best practices for building Ruby applications. Additionally, the blog covers Ruby meetups, events, and job opportunities in the Los Angeles area, fostering collaboration and networking within the local Ruby community.

RUBYLAND

Workflow engines should separate declarative DAG definitions from imperative node execution code, rather than blending them into a single codebase. Systems like Nuke and Terraform maintain strict boundaries between workflow orchestration (the DAG) and actual task execution (the nodes), with communication only through defined interfaces. Modern workflow systems like Vercel's "use workflow" and Temporal attempt to hide this separation, creating "three-colored" code with unclear execution semantics, non-deterministic behavior, and hidden complexity. The author advocates for explicit DAG-based architectures where orchestration and execution remain separate concerns, and warns against using YAML as a compromise declarative language when native language options exist.

On the way to step functions: the two worlds

Congratulations, now your functions have 3 colors