I posted this question on SO that isn’t about meteor per se, but it’s one that meteor seems to solve.
See stackoverflow.com/questions/33948008/identify-a-websocket-from-an-expressjs-request
When you create some object/model via REST API / Ajax, meteor broadcasts that new object to all clients except the one that created it. How is that accomplished exactly?
Meteor actually broadcasts to all subscribed clients - the client that made the change receives data from the server as well. Otherwise you wouldn’t know the outcome of the server call.
Oh really. Thanks for the correction! Why does it wait for a socket message instead of using the REST/API response of the request?
I guess what I’m trying to figure out is how socket messages can be integrated into a traditional json API without causing collisions. For example, my client makes an API post request, the server sends the success/fail response, and the client uses that to insert the object into the view or show an error. Then the other connected clients should get a socket message updating them with what happened.
Is there a good way to combine these two technologies or do I have to give up on the json api and move purely towards socket messaging?
Meteor uses purely sockets, but that isn’t necessarily related. You could easily just ignore the API response and wait for an update over the websocket. I feel like that wouldn’t really introduce any more burden on the server or the client, and you can avoid having a ton of special cases on your code to send updates to everyone except the client that made the write.
Thank you so much for the advice. I will definitely spend some time testing out the different options but it sounds like a pure websocket implementation is the best choice.
Yeah, it seems so - Websockets have additional advantages, for example if you make two requests in a row they are guaranteed to arrive in the right order, which is not the case with HTTP.