Roadmap

[nathanclevenger]

• Simple Example with xstate #2
• Automotive industry state machine example workflow #3
• Utilize defaults to simplify the creation process #5
• Drive hypermedia-based linking to interact with the states #6
• Add api object at top of response for consistency #7
• Add user object at bottom of response from ctx.do #8

[Eduard-Hasa]

Really loving this library. How has it been holding up in production?

[sam-lippert]

@Eduard-Hasa I don't have hard numbers on errors or uptime, but this is one of the most-used libraries in the drivly org. Since this is implemented as a Durable Object in Cloudflare Workers, it is persistent and scalable.
We initialize a state machine for every entry in one database table to track statuses and trigger webhook callbacks, and we use another table to track the state machine event history. This allows us to roll back and replay events for any entity in that table, which is helpful for error debugging and recovery.
One limitation of running this as a Cloudflare Worker is the lack of background functions, so we perform background functions by using callbacks to services such as drivly/alarms.do, which can send events to the machine on a timer.