3 ms·

I would find it a bit strange if you said the application feels a bit snappy vs your previous implementation on REST. I am guessing pretty much that you are in

I would find it a bit strange if you said the application feels a bit snappy vs your previous implementation on REST. I am guessing pretty much that you are in an eyeshot of your server in the figurative sense. Websockets has its troubles. Some ISPs block websockets with some websites so you end up falling back to long polling and it becomes taxing to get a reliable implementation going - some clients just cant connect to a pure websocket. The other is the upfront handshake has a cost or over an unreliable connection, say with a mobile app where REST tends to shine a bit more. Then theres the ability to cache responses across geo-regions, a websocket cannot do this. The other issue is with a REST request you can also do multiple requests at once, with websockets its one at a time, or having multiple websockets to get round that - which makes it worse off.

bruce511 5y ago
>> Some ISPs block websockets with some websites While I'm assuming you have personal experience of this, and I hesitate to make absolute statements, if your connection is HTTPS end to end, I'm not sure how an ISP can "block" it. The ISP sees a regular web connection on port 443, and everything inside that is encrypted. So I'm not sure _how_ it would even know it's web-sockets except perhaps for heuristics on traffic behaviour - and even then it must look similar to keep-alive or HTTP2. With good planning it's easy to do multiple requests on a single socket (the requests themselves would be serialized over the socket, but the server could easily spawn threads to process each request, and then pump the answers back when they are ready.) The connection itself would be serialized, but the handling at either end could easily deal with multiple requests and responses.