Introduction

In one of my past projects, I realized I could have achieved what we were aiming for in a fraction of the time using the tools available now. Camunda would have made the job a walk in the park. However, it would have still required custom workers to implement some of the integration.

At the same time, I also realized that I also noticed the enormous complexity of our deployment model. So complicated that only a few people really understood what was involved. None of it was however abstracted in such a way that it would make the lives of implementers any easier. Despite being merely "a function", it was top-heavy both "weight" as well as complexity.

After WASM/IO 2025, Tiziano Perrucci and I started wondering if we would be able to create WASM-based job workers and deploy them to Fermyon Spin, and make sure the functions themselves stayed lightweight, and have proper abstractions to make it easy to build workers in any language you prefer.

In a way, this project is the result of two big waves crashing into each other. Camunda has been building traction since years, and specifically the move to external job workers has made it a wonderful platform for long-lived business processes. WASM is the other wave, a revolution that slowly changes our technology landscape.

Realization

We defined a contract in WIT, the IDL of WASM components, and then implemented a few "job worker" components capable of registering their interest in specific jobs created by Camunda. Finally, we created a trigger that allowed Spin to respond to Camunda jobs, on top of what it supports as triggers out of the box (HTTP and Redis).

We implemented a few workers, both in Rust and in Moonbit, hooked it up with an example project, and got everything working.

Further Reading

We published our findings in a number of blog posts, but the main one is listed here:

"Job Workers Regimagined: Camunda Meets WebAssembly with Fermyon Spin"