Possible to run server side with immediate execution?

[patwhite]

Really great library guys, very comprehensive and thorough!

I'm looking at xstate for a server side application, where events would be queued to an external messaging system, and the machine would be rehydrated on every event request. I gather this requires a custom interpreter, but after taking a stab at building something, I'm not even sure it's really possible given how much is happening asynchronously.

Do you know if anyone has done anything like this, or would you have any advice on how to go about building something like this?

[davidkpiano]

There's not much that needs to happen asynchronously. Can you please describe your use-case in more detail?

If you mean execution as in action execution, then once you've determined the state, you would execute state.actions on the server-side:

state.actions.forEach(action => {
  // execute action
  action.exec();
});

[davidkpiano]

It's definitely feasible, and one of the main use-cases I'm envisioning for the upcoming v5 (still achievable in v4 though).

Here's the higher-level way that it would work for a request:

1. Persisted state is retrieved from some storage (or machine's initial state if there is none)
2. machine.transition(restoredState, eventFromRequest) to determine the next state
3. Persist that state to the same storage
4. Execute actions (including invoked services)

Invoked services have a special xstate.start action type that you can interpret yourself. This can be envisioned as a "fire-and-forget" action so that the state machine isn't long-lived. The difference is that those invoked services would need a "reference" back to this state machine instance (can just be a URL) so that when it needs to send events back to the machine, it just sends a POST request to that URL.

Stopping an invoked service would be an xstate.stop action that is sent to that running service, so that service can stop itself.

Everything is still short-lived! The original SCXML spec actually contains some interesting insight for this, see the <invoke> section.

When the state is restored, it should not try to restart services or re-execute actions, since that can lead to unintended behavior. But, of course, that's up to you, as you're free to interpret the persisted/restored state as you'd like.

[patwhite]

That's great! Here's where I'm getting a bit hung up - I lifted the interpreter code to work on this:

this.state.children[id] = this.spawnCallback(source, id);

In the model you describe above, state is already persisted so this assignment would essentially be lost. Should this just be refactored out so there is no child persistence?

[patwhite]

But, I think I get the hight level, essentially in that spawnPromise section there, the id should be something that can go to the wire and allow retrieving the statemachine.

[patwhite]

Also, in that model, if two of your fire and forget activities send events to the state machine, you end up with a concurrency issue, unless you do some sort of locking around the machine while an event is being applied. Node solves this by being single threaded, but I don't think that really works in the cloud. I was imagining something where you essentially run all of the activities immediately, except for some sort of explicit transition event which is actually what goes on the wire.

[davidkpiano]

Also, in that model, if two of your fire and forget activities send events to the state machine, you end up with a concurrency issue, unless you do some sort of locking around the machine while an event is being applied.

Good point - this is a non-issue when the state is immediately available, but now that it's being persisted/read somewhere, it's non-zero time. So yes, you would have to add some sort of "lock" to the state (maybe as simple as flipping a locked: true property on it), and to prevent concurrent events from getting lost, they should be kept in a queue.

This lends more to an actor-model system, in which a mailbox for an actor would be that queue.