The title is clickbait, This is just an unstructured document from my ideas and understanding around the actor model
Why I think the Actor model is important
The actor model have very simple concepts that if you understand them, you can model anything (and I really mean anything) as actors.
Actors have logic: either a state machine (preferably) or something deterministic
Actors can receive events or messages however you want to call them. They can ignore events or decide to do nothing about them.
Actors can change its state depending on those messages and its current state
Actors can send messages to themselves or other actors
Actors can spawn other actors usually as child actors, but it does not have to be. they just need a reference to those actors to communicate with them.
THAT'S IT.
Because is very simple, you can think of any piece of software as an actor; any piece I mean at any level: from as big as a machine (which we already do for nodes in our network) to small pieces like a comment (yes, a comment can be modelled as an actor).
Examples of actors
A node in the Hypermedia network
it have a internal logic to function (start, stop, locked, online, offline...)
it has internal state (DB, indexes...)
it can receive events from other nodes
it can update its state depending on the events received
it sends messages to other actors (syncing...)
It can spawn other actors: indexes, documents, comments, feeds, app windows...
A document
it has a deterministic logic (the document machine)
it can receive updates from the parent (by calling discovery)
it can change its state (any document state: loading, idle, editing, rebasing, conflict, saving, publishing...)
it can send messages to other actors and its parent (publish calls a API in the daemon now, when we invalidate some piece of data, we are sending a message to the query cache that then sends an event to all the other components listening to that query cache to update)
it can spawn other actors: after we publish, we spawn small actors that trigger updates in other documents like its parent, or when moving a document we spawn multiple actors to "materialize" that move into multiple document's content.
A comment
it has its own logic to load and show its content
it can receive updates: when a new update to the comment arrives to the node, its cache gets invalidated which triggers an update to the comment
it can change its state: just describe it above
it can send messages to other actors: when publishing it sends messages to the daemon and the query cache
A Feed
it has its internal state (what events is showing, the last cursor shown)
it can receive messages: when new events arrive to the node
it can change its state: show more elements, show more pages...
it can send events to other actors: we can send "seen" events to the backend from here, we can also send events to load content in the background from each event in the feed...
it can spawn other actors: each event can also be modelled as an actor that also listens to cache updates or anything we want...
Why State machines are important in the actor model
When the internal login of an actor is modelled as a state machine, you DETERMINISTICALLY are defining:
All the possible states the actor can be
All the possible events the actor can receive ON EACH PARTICULAR STATE. and this is important
All the possible and valid transitions between states
All its possible context (local state/data)
This way, you can define what happens when anything happens at any state, at any circunstance, you can also define retry loops, error handling, resumable logic... you name it.
This is how you can also let all actors receive any message, because only the messages that are allowed on a particular state for each actor will either make the actor to transition to another state, update its internal context, or just ignore the message.
For me, it drastically changed the way I see software, specially UI, because every section of the app can be modelled this way, and we would just need to make sure the events arrive to those sections.
I'm not going to mention again the magic of visualize state machines again, but this is very powerful not only for technical people but for anyone, and you all know all the current hype around agent factories and loops that are basically ways to visualize this logic based on events.
Because an actor have internal state, if its internals are modelled as a state machine, we can "replay" the events and instrospect its behavior later or in another place in the future. This is good for debugging and "time travel" to have less bugs.
I can talk about all the nice things about state machines, but y'all get bored about this so I will stope here.
Other references
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime