In the case of websockets that is already handled for you. I think GP talks about how to think about communication (client server). Stateless request response

In the case of websockets that is already handled for you. I think GP talks about how to think about communication (client server). Stateless request response cycles are much simpler to reason about because it synchronizes messages by default. The state is reflected via this back and forth communication. Even when you do it via JS: the request data is literally in the scope of the response callback. If you have bi-directional, asynchronous communication, then reading and writing messages is separate. You have to maintain state and go out of your way to connect incoming and outgoing messages semantically. That's not necessarily what you should be doing though.