Duplex messaging between client and server about metacom HOT 9 OPEN

How this approach differs from the regular RPC call from client to server?
If you subscribe on client events, this will have the same effect as RPC because we have connection.on('message', () => {}) in WsChannel, which is actually low level implementation of api.interfaceName.processEvent(({ message }) => {}).

from metacom.

This is different from low-level implementation, because there will be metadata in a packet as well. So packet will be recognized by metadata. In some cases, we need async messaging, e.g. some user activity tracking. So basically RPC - remote procedure call. We run procedure in server and expecting response/error within the call directly. Async messaging - we don't care about immediate response. Notifications, user's actions tracking, any similar functionality

from metacom.

connection.on('message', () => is far not the same as api.interfaceName.processEvent(({ message }) => {}). There is an interfaceName metadata provided withing the packet. So this is an alternative solution, and it looks worse than proposed.

from metacom.

Let me clarify - by saying low level implementation I mean connection.on('message', (msg) => {}), which is placed in WsChannel class and works as a subscription to client messages including protocol metadata like interface name.
It means that api.interfaceName.processEvent(({ message }) => {}) will need additional message subscription.
But do we really need it, while it can be implemented as a simple interface call, where user's metadata is defined by the user and the result of that call is ignored and not awaited?

from metacom.

The alternative solution just brought confusion to the topic. I removed it. So speaking about proposed solution. It is just mirroring existing functionality, and of course I see this useful to have in metacom. So developer don't need to go to a low level at all and stay within the metacom only, cause metacom is a high-level network library compare to raw WS

from metacom.

Server-side, we have no direct link to a WS connection available. This would break our abstraction layers. So we need to have such functionality implemented. For client, I am sure it is the same. By design, we don't need to go directly to a WS connection, just to not break abstraction layers/

from metacom.

@tshemsedinov
Need your thoughts on this issue

from metacom.

Client code is ok for me, but server-side event handler I'd like to have, for example, file onEventName.js with the following code:

({ message }) => {
  if (message === 'hello') {
    context.client.emit('interfaceName/event', 'hi');
  }
};

from metacom.

Can we implement server-side event handlers as it is?
We have application.getMethod(iname, ver, methodName) in impress for rpc calls, but don't have analogue for events
(sth like application.getEvent(iname, eventName))
We can do client-side event emitting though.

from metacom.