Comment by jFriedensreich | Hacker News Reader

Comment by jFriedensreich | Hacker News Reader

There is a concerning cargo cult feedback loop in the industry fueled by companies offering websocket based solutions and writing long articles about everything that this COULD be used for and young developers half heartedly looking for solutions and then defaulting to websockets for anything with some server push or realtime requirements. Websockets are bad advice for sending tennis-match data and reddit-comment counters to a client, websockets are bad advice for messenger/ chat applications and most other things used as an example. They are mostly useful for things where high frequency bi-directional communication is required such as syncing multiple cursors, player positions/actions in realtime games and visual co-editing such as figma. (every 5+ seconds is not high frequency) If you are not building one of those chances are high you are being lured into that cargo cult. All you need is http2 and SSE or streaming fetch. Websocket companies will tell you all about how most problems are solved by their offerings or fancy frameworks but ignore the fact those problems could be not there in the first place. And also inexperienced developers that never operated websocket based solutions over a few years or millions of users will be very quick to lecture you about how they never had any problems or headaches, because its hard to admit that you skipped proper solutions research.

Disclaimer: I work for Ably. I agree that it's not valid to claim that websockets are the best fit in every situation. If the requirement is simply to stream server to client events, in an application where that doesn't depend at all on having any per-client state, then you can serve those things statelessly with SSE or HTTP/2. However, much of the time, the thing that makes websocket implementations complex isn't anything to do with websockets per se, but the fact that the server has per-client state; this state needs to exist somewhere in the backend, and it needs to survive reconnections (and so can't simply be some ephemeral session state in the specific server handling a connection). In this case, you could be using HTTP/2, or comet over HTTP1, or websockets, and the main technical issues you will face scaling to millions of users are going to be essentially the same. Websockets (at least, until web transport is here) just give you a more convenient and efficient primitive.

This is perfect example for my remark. With HTTP/2 and SSE you use the exact same feature of your framework to have server side state that would solve this between requests or in any other situation, there is no new problem to solve! Apart from that fact, server side per connection state is usually an anti-pattern, not a common situation as you put it. As far as i can think right now, the only situations where this is required and cannot be solved with better caching would be the same bi directional high frequency streaming situations already mentioned.

So then how would you solve it without state? For someone like me who is new to the reading these comments I hear a lot of bickering / arguments but no provided solution

Depends what "IT" is. If you give me one or a few examples what you want to solve I am happy to give more concrete feedback.

I mostly agree with this - right tool for right job.

> They are mostly useful for things where high frequency bi-directional communication is required such as syncing multiple cursors, player positions/actions in realtime games and visual co-editing such as figma.

This is the only use case for websocket I have personally found - streaming user input to the server. Anything that goes server->client can just be some variant of fetch that is invoked as needed.

In my use cases, I stream player mouse events (via pointer lock API) over the socket. Depending on the browser/os/mouse, this can be hundreds per second.

Reply on news.ycombinator.com