Hacker News Reader

Comment by anderspitman | Hacker News Reader

I used to love WebSockets a lot more. At some point I got deeper into implementing HTTP servers and proxies, and realized how much of a special case WebSockets are to implement. They're cool, but I prefer Server-Sent Events on HTTP/2 whenever I can get away with it, which is pretty much always (binary data being a big exception, and even then I consider long-polling first).

I think there's value in keeping our protocols as simple as possible to accomplish the task at hand.

View on HN

I feel like websockets get waaay too much hype and attention compared to SSE, especially for use cases that are barely interactive at all.

Future-proofing is a good use case though. As a developer I don't want to maintain both SSE and WebSockets, since they solve similar problems and WebSockets are a superset of SSE. Even though my WebSockets implementation is currently unidirectional (server to client), I still opted for that over SSE because I'll probably need send data the other way at some point in the future. Why learn two tools when I can just learn one?

What's wrong with normal HTTP requests for client->server streams? You get the added bonus of being able to dump them to a curl command for debugging.

More overhead, and it doesn't scale. My nodejs websockets server can handle thousands of connections without a problem, but my rails api server allocates a thread per connection so I'm limited to <16 unless I start horizontal scaling.

For infrequent requests everything goes through the api, but for stuff like chat and live-document-editing, nodejs is the better solution.

I think I missed something. Why can't you use node for SSE?

I can, but why would I limit myself to one-way communication when I can have bidirectional communication?

You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

But to answer this new question:

* You can have bidi without WS.

* Because WS is more complicated.

> You didn't cite bidi as your reason for choosing WS in your last comment, you cited scaling and node vs ruby.

Because I was answering this question: "What's wrong with normal HTTP requests for client->server streams?"

> You can have bidi without WS.

Only by combining HTTP (which doesn't scale because my api server runs rails) and SSE (which does scale). If I want scaling bidirectional communication, I need websockets.

> Because WS is more complicated.

More complicated than SSE? I don't think so.

If you use nginx, you can use the excellent nchan module to push messages by having your backend make a POST request to nginx. Clients can connect to nchan via websockets, SSE, and few other things like long polling without your app having to support all of them. Been using it for a recent project and really like it.

Sadly it's not entirely unfounded. SSE on HTTP/1.1 is basically useless due to the connections-per-domain limits implemented in browsers. So WebSockets got a lot of mindshare while we waited for HTTP/2.

But today I always start with plain HTTP, then try SSE, and finally WebSockets if I have to.

And using SSE with Hotwire is even easier than using WebSockets: https://mercure.rocks/docs/ecosystem/hotwire

I've used HTTP/2 SSE for TinyDev (docs.tinydevcrm.com) and I've encountered the need for a reverse proxy and the unidirectional dataflow to be kinda eh, even if it is great in theory. I haven't played around too much with WebSockets though, but IMHO money + traction carries a good deal of weight.

Isn't HTTP/2 SSE being deprecated?

I sure hope not. Are you thinking of HTTP/2 server push?

https://stackoverflow.com/questions/28582935/does-http-2-mak...

I've seen nothing to suggest SSE would be (or is even capable of being) deprecated on HTTP/2.

You may be confusing it with HTTP/2 Push, where a server can inform a client of a future resource it will need, which is _de facto_ dead, with only a few real implementations beyond the bare minimum required by the HTTP/2 specification.

Why do you require a reverse proxy, and are those requirements unique to SSE for some reason?

I guess I'm not seeing what the alternative setup would be, even with WebSockets.

I'm also sad that SEE's don't get the attention and love they deserve.

You might check out https://braid.org, which is like SSE but specifically for updating state at URLs, and works for binary data.

Thanks. Braid looks interesting, but complex and mathy. It's not clear to me what the use cases would be or why I would choose it over SSE or WebSockets for any given problem.

That's good feedback, thank you. I think we'll be able to get clearer use-cases there within the next few months.

Reply on news.ycombinator.com