Philosophy behind stepper_motor

Historically there has been a few tools which allow durable execution workflows in Rails. Just a few worthy examples come to mind:

• acidic_job tackles jobs performed in bulk and inside a transaction
• aasm adds state machines to Ruby classes (and ActiveRecord)
• Batches in good_job provide a limited "fork and join" experience

...and, of course, there is a juggernaught in the form of Temporal.io

Yet, confronted with a task of creating an "account attrition" flow - where there are some actions performed in addition to reminding the user they are about to churn - I was a bit surprised. There were no tools available for this.

The closest was heya from HoneyBadger. It was "so close it was palpable" - the step definition was there, the persistence was addressed. But something didn't jive there in terms of style. Besides, while Heya has a number of great facilities for dealing with drip email campaigns, doing other activities in it proved to be difficult.

Another thing lacking in Heya was the fact that there was limited to no "flow control", and a specific campaign (what came to be known as Journeys in stepper_motor) could only be halted for a specific person using a fairly inconvenient API. For our use case, we needed to be able to control a specific journey a user goes through in detail, and do so inside of the steps we perform.

Thus: stepper_motor. A durable execution engine for the rest of us.