Comment by paulbjensen

Although WebSockets are simple to use, there are a bunch of issues that the spec doesn't cater for when using them:

1. Connectivity. The WebSocket connection is only as persistent as the underlying network connection between the client and the server. A person playing a web-based game on a mobile device on a train that then goes under a tunnel is a good example.

WebSockets do not reconnect if they close unexpectedly. In such cases, you have to throw the WebSocket instance away and create a new one, and so you end up having to implement your own reconnectivity logic.

2. Message Sending. Messages will only be sent if the connection is open. If it is closed, not only do the messages not get sent, but they don't get queued up either, so they end up disappearing into the ether.

If you want to guarantee message sending, then you end up having to implement a queuing mechanism that is linked to knowing the status of the WebSocket connection, and is able to send when the conditions are right.

3. If you don't use WSS (WebSocket Secure Server) for the WebSocket host and connection url, then the WebSocket connections can get interfered with if they are connecting over a mobile network - ISPs sometimes inject packets which ends up distorting WebSocket connections over http. But I think since the days of Ed Snowden's leaks everyone has their production WebSocket systems setup using WSS.

This comes from the experience many years ago of working on a WebSocket-powered web framework called SocketStream which ran into these issues, and then some years ago I managed to build a library that focussed on dealing with those WebSocket-related issues, called Sarus: https://github.com/anephenix/sarus

WebSockets is great though, and there is still much that can be done with it as this library in the HN post demonstrates.