A Real Batch Job Puts The Elm Architecture to the Test
A real batch job running on elm-run explores union-type state machines, type-safe retry/rewind, and domain models shared with a Lamdera app.
To stress-test the native Elm runtime elm-run, the author swapped a toy proof-of-concept for the real, sizeable batch job inside an actual application. Unlike elm-pages' Script mode, which chains steps as a linear BackendTask pipeline, this exercise ran a genuine Elm Architecture loop—init, update, subscriptions—against the operating system instead of the browser, which turned out to matter a lot for a job babysitting hundreds of items each drifting through multiple states and occasionally failing midway.
Each batch item is modeled as a union type spanning states like Queued, Submitted, Processing, Finished, and Failed, so illegal transitions—like fetching a result for something never submitted—become unrepresentable at compile time. Because the Failed variant carries the entire prior Item, rewinding a failure is just returning to that previous state, turning retries from 'restart and hope it's idempotent' into 'resume from where you left off.'
The piece argues this discipline matters more for batch workloads than for UIs: an unhandled case in a frontend is a visible stuck spinner, but in a batch job it's a silent skip nobody notices until much later, which is exactly where exhaustive pattern matching pays off. Because update is a pure function, replaying recorded message sequences lets the author test resume-from-checkpoint behavior without touching IO.
The most striking part is architectural: the same Elm domain types, encoders, and decoders now run across three runtimes—a Lamdera frontend, a Lamdera backend, and a native batch binary compiled via elm-run—eliminating an entire class of drift bugs between client and worker that untyped boundaries typically accumulate over time.