Architecture

Actor Systems hold all the information about the location of all the actors on an application, even if they are in memory or not. They are composed of: Materializers Resolvers A Top Level Supervisor Fibers Mailboxes

Fibers represent green threads with a set of resources. Usually, an application will contain only one fiber (because JavaScript only exposes one single thread, with an event loop), however, it’s possible to have multiple fibers when you are working with webworkers. Fibers offer CPU ticks to processors, that will use them to process actor mailboxes.

Mailboxes are a queue of messages with guaranteed ordering. Mailboxes have a set of useful properties that make them really powerful: Mailboxes are partitioned. It means that messages are distributed through partitions, and subscribers can read from different partitions. Mailboxes are dynamic. You can subscribe and unsubscribe from a mailbox many times. They guarantee ordered/only once delivery. Even if an actor can process the same message more than once (depending on the recovery strategy), the message will be only delivered once by the mailbox.

Materializers are hooks over the lifecycle of an actor. They are used to add implicit infrastructure logic to an actor. Some use case of materializers are, actually, two main tarant modules tarant-vue and tarant-local-storage that let us render actors and save their state in the local storage of the browser, for later recovery. A materializer can implement the following methods: onInitialize(actor: Actor) when the actor is first created. onBeforeMessage(actor: Actor, message: ActorMessage): void when the actor is going to process a message.

Resolvers let us find actors that have been persisted in external systems, like databases or storages. One example of resolver, is the tarant-local-storage module, which let us recover actors that have been persisted in the local storage, without losing information. Resolvers must implement the following method: resolveActorById(id: string): Promise<Actor>. If the actor exists in the storage, return a promise of the configured actor, if not, returns a promise with undefined.

Supervisors are the responsible of handling actor failures and deciding the strategy to recover. There are two types of supervisors. Top Level Supervisor The Top Level Supervisor is an object that implements the IActorSupervisor interface. The Actor System delegates all errors to the top level supervisor. Actor Supervisor Actors behalf as supervisors of their child actors. When a child actor fails, the parent will decide which strategy to follow to recover.