Refactor the C/S proxy mechanism with the actor model

[unadlib]

reactant-share uses a one-to-many client design, which relies on class method proxies that trigger the server's execution methods.

class Counter {
  @state
  count = 0;

  @action
  _increase() {
    this.count += 1;
  }
  
  @proxy
  async increase() {
    this._increase();
  }
  
  async doSomething() {
    await this.increase();
  }
}

For developers, the principle of using @proxy is difficult to grasp, and the decorated methods often have to be newly written in order to have to be asynchronous, thus necessitating a new simple asynchronous method, which is not worth it.

Therefore, reactant-share requires a more flexible and simple C/S proxy model, and the actor model is well suited for such a design.

class Counter {
  @state
  count = 0;

  @action
  increase() {
    this.count += 1;
  }
  
  async doSomething() {
     await spawn(this, 'increase', []);
  }
}

[huanhulan]

IMHO, It should call send instead of spawn, spawn meaning creating an actor who has his unique address and waiting for and processing messages coming into its own mailbox in his own "thread."

In this case, I think the actors are: server script, channel, and client tabs which already exist before you call the spawn? and doSomething means sending the message to a client tab actor which forwarded by a channel actor? Plz correct me if I were wrong about this.

[unadlib]

Hi @huanhulan, In fact, it can't really be an actor model, the actor thread exists before spawn is executed, it is the server thread, and there is only one.

I only proposed this change because I thought it would be easier to understand the actor model.

Of course, maybe this API should not be called spawn(), maybe act() is also appropriate. But I finally chose spawn() because it is the most similar of most programming models, and although they are both parallel computing, they are not essentially the same.

[huanhulan]

Hi @huanhulan, In fact, it can't really be an actor model, the actor thread exists before spawn is executed, it is the server thread, and there is only one.

I only proposed this change because I thought it would be easier to understand the actor model.

Of course, maybe this API should not be called spawn(), maybe act() is also appropriate. But I finally chose spawn() because it is the most similar of most programming models, and although they are both parallel computing, they are not essentially the same.

IMHO, it is a legit actor model.

Take shared worker multi-tab syncing as an example. There are two kinds of actors:

1. client actors: tabs, do all the things a client app suppose to do. Client actor doesn't know each other and only has the address of the shared worker.
2. a channel actor: a shared worker, only supports two behaviors - put a message, get a message. It has all the addresses of client actors.

The first client actor's bootstrapping spawns a channel actor while the rest of the app's lifetime, other client actors are created by the browser.

The example above has no spawning actors unless we see the browser as a root actor. And it's totally ok even we don't have a semantic of spawn by the definition of the actor model:

1. The actors above are isolated by browser process model,
2. and each actor has its own mailbox address (connectionId) and mailbox (onMessage callback) with finite behavior for messages.
3. the whole system is indeterminate

Then by knowing this, we can change the semantics of the API from spawn(module, key, args) to send(address, {module, key, args}) for the sake of clarity. Furthermore, since the address can only be the shared worker for the example I mentioned, we can confidently curry the function into another helper function like: sendToSharedWorker

[unadlib]

Hi @huanhulan, In fact, it can't really be an actor model, the actor thread exists before spawn is executed, it is the server thread, and there is only one.
I only proposed this change because I thought it would be easier to understand the actor model.
Of course, maybe this API should not be called spawn(), maybe act() is also appropriate. But I finally chose spawn() because it is the most similar of most programming models, and although they are both parallel computing, they are not essentially the same.

IMHO, it is a legit actor model.

Take shared worker multi-tab syncing as an example. There are two kinds of actors:

1. client actors: tabs, do all the things a client app suppose to do. Client actor doesn't know each other and only has the address of the shared worker.
2. a channel actor: a shared worker, only supports two behaviors - put a message, get a message. It has all the addresses of client actors.

The first client actor's bootstrapping spawns a channel actor while the rest of the app's lifetime, other client actors are created by the browser.

The example above has no spawning actors unless we see the browser as a root actor. And it's totally ok even we don't have a semantic of spawn by the definition of the actor model:

1. The actors above are isolated by browser process model,
2. and each actor has its own mailbox address (connectionId) and mailbox (onMessage callback) with finite behavior for messages.
3. the whole system is indeterminate

Then by knowing this, we can change the semantics of the API from spawn(module, key, args) to send(address, {module, key, args}) for the sake of clarity. Furthermore, since the address can only be the shared worker for the example I mentioned, we can confidently curry the function into another helper function like: sendToSharedWorker

In fact, the SharedApp has a compatibility mode. In the traditional SPA mode, spawn just calls its own module methods. In SharedApp mode, it will send to a server "thread" which may have rendering for example (SharedTab mode) or renderless (SharedWorker mode or ServiceWorker mode). Also, its address (which I understand to be "tabId/server") is in fact not used very often, and it should not even be used for the sake of model simplicity. Overall, I don't think send has good semantics.

Let's confirm the similarities between the actor model and the current proxy mechanism,

An actor is a computational entity that, in response to a message it receives, can concurrently:

• send a finite number of messages to other actors;
• create a finite number of new actors;
• designate the behavior to be used for the next message it receives.

There is no assumed sequence to the above actions and they could be carried out in parallel.

Except that SharedApp's proxy mechanism does not include the ability to continuously create actors, but the other parts are largely similar.

The spawn in the actor model includes the creation of threads/parallel execution/response/state sharing, and so on. The spawn in SharedApp has similar behavior, except that it does not include "thread" creation, which needs to be more explicitly explanation.

Finally, I want to make it clear that no matter which API name it is called, it should not use addresses for the sake of a more concise model, it should only be used for clients, and clients should not interact directly with each other, they should interact indirectly through the "server" port.

About "send/spawn/act", all three names have their advantages and disadvantages, I first chose the name act, but it needs to explain a lot of things, in order to quickly express the "actor", and finally choose the name spawn.

[unadlib]

If the API name uses send, it usually means that there should be an explicit receive/listen API as well. But in fact, the SharedApp proxy mechanism does not require an explicit receive/listen API.

[huanhulan]

If the API name uses send, it usually means that there should be an explicit receive/listen API as well. But in fact, the SharedApp proxy mechanism does not require an explicit receive/listen API.

Make sense

[unadlib]

Thanks for the discussion, and need to add that SharedApp is also allowed for messaging. In SharedTab mode, the server/client roles are allowed to switch between each other.

class Foo {
  constructor(
    private portDetector: PortDetector,
  ) {
    this.portDetector.onServer((transport) => {
      // transport.emit/transport.listen
    });
    this.portDetector.onClient((transport) => {
      // transport.emit/transport.listen
    });
  }
}