Your backend should probably be a state machine
docs.statebacked.dev
Your backend should probably be a state machine
1–10 of 15 posts
Re: Your backend should probably be a state machine
#2Hey! Leave my physique out of this...
Re: Your backend should probably be a state machine
#3Really interesting framework for thinking about backend systems. I've been messing around with LLMs, and there's a real need to check and constrain outputs when building anything rigorous. I've only been working through static workflows, but can imagine it only gets more complex if the workflow changes dynamically based on the LLM output. I wonder if this state-machine-based back end is a good way to better manage that.
Re: Your backend should probably be a state machine
#4Really interesting framework for thinking about backend systems. I've been messing around with LLMs, and there's a real need to check and constrain outputs when building anything rigorous. I've only been working through static workflows, but can imagine it only gets more complex if the workflow changes dynamically based on the LLM output. I wonder if this state-machine-based back end is a good way to better manage th…
Great point! State machines are a really nice way to orchestrate multi-step LLM invocations.
They're also a great way for LLMs to produce code. It's human-readable so you can vet that it's doing what you want it to and it's high-level enough that the remaining bits to fill in tend to be small functions that AI can easily generate.
Re: Your backend should probably be a state machine
#5I found the contrast with workflow systems such as Cadence/Temporal really interesting. You can tell the author has felt the pain of managing real time distributed state machines.
Re: Your backend should probably be a state machine
#6I found the contrast with workflow systems such as Cadence/Temporal really interesting. You can tell the author has felt the pain of managing real time distributed state machines.
Thank you! These workflow systems were such an amazing advance over what came before but we can do even better.
Re: Your backend should probably be a state machine
#7The systems available today (Temporal/Cadence/etc) definitely make a big mess of updating logic/code. This seems so obvious and yet I've not seen it done well -- excited to see where it goes!
Also my first time hearing of the Slemiel the painter algorithm (or at least first time hearing it described that way). Thanks for sharing
Re: Your backend should probably be a state machine
#8The systems available today (Temporal/Cadence/etc) definitely make a big mess of updating logic/code. This seems so obvious and yet I've not seen it done well -- excited to see where it goes! Also my first time hearing of the Slemiel the painter algorithm (or at least first time hearing it described that way). Thanks for sharing
Thanks! Running systems with this pattern for the past few months, it has been so nice being able to cleanly upgrade instances.
The old Joel on Software blog has some gems.
Re: Your backend should probably be a state machine
#9That's what she said.
Re: Your backend should probably be a state machine
#10We're still waiting for our "react" moment on the backend; a fundamental shift in the abstractions we treat as the bedrock of our applications.
I think the author does a good job here showing why the state machine might just be that abstraction.