5 ms·
On the contrary, in my experience such stateful APIs are a great use case for state machines. You just approach them differently. Instead of doing a blocking ca
by mr_olive 6y ago
On the contrary, in my experience such stateful APIs are a great use case for state machines. You just approach them differently. Instead of doing a blocking call, you introduce a "waiting for <something>" state. You leave the "blocking" state when the correct event comes, or after a timeout. And while you are waiting for the event, you don't just burn CPU cycles, but yield control quickly, so that other threads can execute in the meantime.
- chrisweekly 6y agoI don't have much experience w them yet, but found the xstate lib well-documented, and also like swizec's take: https://swizec.com/blog/when-your-brain-is-breaking-try-xstate/ https://swizec.com/blog/when-your-brain-is-breaking-try-xsta...
- adamkl 6y agoAdditionally, you can use state machines server side to track stateful processes by simply serializing the “current” state of the machine and storing it somewhere. With the next request, reload the “current” state of the machine and transition to the next based on the incoming request. Rinse/repeat.
- stainforth 6y agoCan webhooks come into play nicely with state machine models?
- billfruit 6y agoThe thing is, wont calling a blocking api block a lot of things the statchart is supposed to be doing at the same time?