Great video, Gavin. I’m very interested in implementing XState into my own backend projects, so it’s great to see this video. Edit: Also, don’t stop. The more backend examples, the better.
This was very well presented and informative Gavin, thank you! A link to a video or docs about storing states and context and resuming the workflow would come in handy though!
Thank you. I would like to learn the best practices of using xstate for long living actors - like eshop cart, where you trigger events from the frontend and get next state from server. Maybe using the same state machine on frontend and backend only with injected different actors in each environment. And when you store some snapshot to database, how do you handle migrations, when state machine definition changes?
Hi Viliam! Thanks for the feedback, and you’ve brought up a use case we’ve heard a few times. State machine migrations for live actors is something we’ve been thinking on for quite some time, so I think it’s worth some exploring in the lab!
Thanks for the feedback @pheisar! If you’re using an XState machine, it kind of makes step functions a bit redundant, so I would just use a lambda. If your tasks are more long-running and could exceed the runtime’s time constraints, you can definitely save the state to a DB or storage account, and then rehydrate whenever the function is woken up again. We have a small rehydration example in the XState repo with MongodDB as a backing store.
Great video thanks! Once you generated a state machine and you've hooked up the generated code in your codebase, how does that work when you update the state machine in the UI? Do you have to manually hook up the entire updated state machine? Or is there some sort of automation? Thanks
Great video, Gavin. I’m very interested in implementing XState into my own backend projects, so it’s great to see this video.
Edit: Also, don’t stop. The more backend examples, the better.
Gavin, you've got a great presentation style. I really enjoyed this. Incredible work happening over at Stately.
PLEASE MORE FROM THIS!🎉
This was very well presented and informative Gavin, thank you! A link to a video or docs about storing states and context and resuming the workflow would come in handy though!
Thank you. I would like to learn the best practices of using xstate for long living actors - like eshop cart, where you trigger events from the frontend and get next state from server. Maybe using the same state machine on frontend and backend only with injected different actors in each environment. And when you store some snapshot to database, how do you handle migrations, when state machine definition changes?
Hi Viliam! Thanks for the feedback, and you’ve brought up a use case we’ve heard a few times. State machine migrations for live actors is something we’ve been thinking on for quite some time, so I think it’s worth some exploring in the lab!
Finally!!!! A backend video!!! Using xstate!!!
Great video! If i wanted to use xstate on aws instead of a step function, what would be the runtime you'd recommend? Just a regular lambda? Thanks!
Thanks for the feedback @pheisar! If you’re using an XState machine, it kind of makes step functions a bit redundant, so I would just use a lambda. If your tasks are more long-running and could exceed the runtime’s time constraints, you can definitely save the state to a DB or storage account, and then rehydrate whenever the function is woken up again. We have a small rehydration example in the XState repo with MongodDB as a backing store.
Great video thanks! Once you generated a state machine and you've hooked up the generated code in your codebase, how does that work when you update the state machine in the UI? Do you have to manually hook up the entire updated state machine? Or is there some sort of automation? Thanks
Good job! Thank you very much!