I appreciate some events can be asynchronous for clients, for example: actions taken by other users, or events generated by the system. However, I do think impl

I appreciate some events can be asynchronous for clients, for example: actions taken by other users, or events generated by the system. However, I do think implementation details (using async in the server) should be encapsulated from clients: when users save a new document, it's much easier for the client to receive a useful albeit delayed response, rather than "event submitted", wait for the result on a stream. Of course, other relevant clients may need to hear about that event too. The service architecture should not affect / make-life-harder for clients. Therefore I think disagree with both parent and grandparent comments. Use each when they make sense, not "synchronous by default" (grandparent comment, though I do think there are good points made), or "asynchronous based on service architecture" (parent comment). > But my better solution is to pull the async-ness all the way out to the client: https://matssocket.io/ https://matssocket.io/ Is that a solution that you use? I took a look at matssocket https://www.npmjs.com/package/matssocket https://www.npmjs.com/package/matssocket, it currently has 2 weekly downloads. :thinking:.