7 ms·
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
by anderspitman 6y ago
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.
- yingw787 6y agoI'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.
- tschellenbach 6y agoIsn't HTTP/2 SSE being deprecated?
- anderspitman 6y agoI sure hope not. Are you thinking of HTTP/2 server push?
- iomcr 6y agohttps://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete https://stackoverflow.com/questions/28582935/does-http-2-mak...
- jamescun 6y agoI'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.
- anderspitman 6y agoWhy 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.
- iomcr 6y agoI feel like websockets get waaay too much hype and attention compared to SSE, especially for use cases that are barely interactive at all.
- viklove 6y agoFuture-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?
- anderspitman 6y agoWhat'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.
- viklove 6y agoMore 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.
- anderspitman 6y agoI think I missed something. Why can't you use node for SSE?
- viklove 6y agoI can, but why would I limit myself to one-way communication when I can have bidirectional communication?
- phaedryx 6y agoI'm also sad that SEE's don't get the attention and love they deserve.
- kdunglas 6y agoAnd using SSE with Hotwire is even easier than using WebSockets: https://mercure.rocks/docs/ecosystem/hotwire https://mercure.rocks/docs/ecosystem/hotwire
- toomim 6y agoYou might check out https://braid.org https://braid.org, which is like SSE but specifically for updating state at URLs, and works for binary data.
- anderspitman 6y agoThanks. 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.
- toomim 6y agoThat's good feedback, thank you. I think we'll be able to get clearer use-cases there within the next few months.