When to split up machines?

[weary yacht]

I'm building a rather complicated app with "multiplayer" realtime interaction. So I started building the basis of the app in a machine (the user joined the group, entered a session, the session started, etc...) and I want to continue fleshing this out.

So I'm thinking of creating a "Timer" state that keeps track of the the elapsed time, whether a session has started, what events have happened in this session, etc...

And it only continues from there.

The different states have dependencies, and I'm now wondering if I should build all of this in one huge Machine, or if I should split them up into multiple machines and use them as actors to communicate.

Any help would be greatly appreciated!

[placid goblet]

As usual, it depends. There's a trade off here. If you keep them in a single machine, the entire behavior is more tightly coupled and everything plays as one whole thing but it will be a big definition so more code, more chore.
If you split them up into multiple actors, you'll get smaller stateful chunks of behavior but then you'd need to sync their behavior together when there's a flow that crosses more than a single actor. If the behavior of one actor should depend on the behavior of another one, then you'd need to guard against those and you'd probably end up with more events because now you need explicit events for actors to talk to each other (not a bad thing).

With multiple actors, you might need to have some integration tests to test cross actor flows whereas with a single huge statechart, integrations are fault tolerant if not impossible cause transitions are inside a single machine.

[weary yacht]

Ok so it is not per se a bad practice to put a lot of logic in one machine. And if it becomes too big I can split it up later right?

[placid goblet]

Multiple actors = multiple context + sync events
Single big actor = single context + internal transitions

[weary yacht]

Ic ic... I think then in my case a single machine is probably not the stupidest idea.

[placid goblet]

You can always split it up and the definition of big and unmaintainable is different per case so no, not a bad thing at all.

[weary yacht]

If I wanted to split it up, is it common to have a root machine that has the other machines (actors) in the context and build it like this?

[placid goblet]

It's a known practice, in fact it has a name, the 'receptionist pattern'

[weary yacht]

Ok. And that would be the usual approach for a complete app too? Or is it more common to maintain the machines separately and take care of forwarding outside a machine?

[placid goblet]

Different projects do this differently. Stately viz for example uses multiple actors with no supervisor actor

https://github.com/statelyai/xstate-viz

[weary yacht]

Thank you so much. You have been a huge help. If I may ask a last question (I'll probably find in the docs):

If there are multiple (parallel) states in a big machine, how does a parallel state get an update from another one. Would that be the role of the state where an event happens to send it to the other state?

I think that was a stupid question because inside a machine I just send my events as usual to other states (or listen to context changes)

Im a bit confused because I looked at so many patterns 🙂

Thanks again for your help!

[placid goblet]

Yeah, all the communication happens through events.

[placid goblet]

It's quite normal to feel overwhelmed with these in the beginning. My recommendation is to go for multiple actors with no supervisor actor by default if you really want to separate actors.

I don't have a strong case for a supervisor actor yet