Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Server-Sent Events: an alternative to WebSockets

germano.dev

Post reply on HN
Print view View original

251–260 of 266 posts

Re: Server-Sent Events: an alternative to WebSockets

#251

Post by coder543 »

kreetx wrote: post #250
coder543 wrote: post #70

Earlier quoted context omitted.

Browsers also limit the number of websocket connections. But, if you're using HTTP/2, as you should be, then the multiplexing means that you can have effectively unlimited SSE connections through a limited number of TCP connections, and those TCP connections will be shared across tabs. (There's one person in this thread who is just ridiculously opposed to HTTP/2, but... HTTP/2 has serious benefits. It wasn't develope…

Right, but this article argues that SSE is simple and easy to debug on the wire - so is http1. Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore. The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.

> The SSE connection limit is a nasty surprise once you run into it, it should have been mentioned.

It does not apply to HTTP/2, as previously noted.

> Http2 is easy to set up, so are websockets, yet debugging the multiplexed http2 stream is is not that simple anymore.

I have literally never heard of anyone I personally know having to debug HTTP/2 on the wire. Unless you believe there are frequently bugs in the HTTP/2 implementation in your browser or the library you use, this just not a real concern. HTTP/2 has been around long enough that this is definitely not a concern of mine. I would be more worried about bugs with HTTP/3, since it is so new.

Websockets are also not especially easy to set up… they don’t work with normal HTTP servers and proxies, so you have to set up other infrastructure.

Re: Server-Sent Events: an alternative to WebSockets

#252

Post by hamburglar »

gmfawcett wrote: post #236
hamburglar wrote: post #156

Earlier quoted context omitted.

Personally, while I appreciate the difference from a promotion-of-FOSS point of view, I find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source” and start these kinds of arguments in threads where non-completely-free software whose source is open comes up. We haven’t all agreed on your terminology, and the argument is not “settled” except in the minds of the folks who…

> I find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source” Since when was "open source" generic? These obnoxious idealists you're complaining about are the people who invented the term in the first place.

Since the several decades before a few people decided to co-opt it for strategic political reasons. You apparently don’t remember the arguments over whether they should be called “free software” or “open source.” Both terms were already in use. I grew up downloading shareware, some of which was open source and some of which was not. It almost universally came with a limited use license and a request for some money if you used it. This is how Unix started too. Limited license with open source code. You can send your changes back to us but you can’t distribute them.

Re: Server-Sent Events: an alternative to WebSockets

#253

Post by hamburglar »

hamburglar wrote: post #252
gmfawcett wrote: post #236

Earlier quoted context omitted.

> I find it obnoxious that FOSS idealists think they can dictate the usage of the generic phrase “open source” Since when was "open source" generic? These obnoxious idealists you're complaining about are the people who invented the term in the first place.

Since the several decades before a few people decided to co-opt it for strategic political reasons. You apparently don’t remember the arguments over whether they should be called “free software” or “open source.” Both terms were already in use. I grew up downloading shareware, some of which was open source and some of which was not. It almost universally came with a limited use license and a request for some money if…

RMS has even published an essay talking about how the term “open source” is a poor choice because it has an obvious common sense definition that means “you can see the source.”

Re: Server-Sent Events: an alternative to WebSockets

#254

Post by herodoturtle »

mceachen wrote: post #190
herodoturtle wrote: post #48

Earlier quoted context omitted.

Been reading all your comments on this thread (thank you) with interest. Can you recommend some resources for learning SSE in depth?

https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...

This was awesome!

Thanks!

Re: Server-Sent Events: an alternative to WebSockets

#255

Post by jupp0r »

bullen wrote: post #67
jupp0r wrote: post #56

Earlier quoted context omitted.

The issues with TCP head-of-line blocking are resolved in HTTP/3 (QUIC).

Sure but then HTTP/3 is still binary and it's in flux meaning most routers don't play nice with it yet and since HTTP/1.1 works great for 99.9% of the usecases I would say it's a complete waste of time, unless you have some new agenda to push. Really people should try and build great things on the protocols we have instead of always trying to re-discover the wheel, note: NOT the same as re-inventing the wheel: http:/…

Routers are operating on the IP layer of the network stack, they don't have anything to do with application level protocols.

Re: Server-Sent Events: an alternative to WebSockets

#256

Post by mythz »

easrng wrote: post #216
mythz wrote: post #42

We use SSE for our APIs Server Events feature https://docs.servicestack.net/server-events with C#, JS/TypeScript and Java high-level clients. It's a beautifully simple & elegant lightweight push events option that works over standard HTTP, the main gotcha for maintaining long-lived connections is that server/clients should implement their own heartbeat to be able to detect & auto reconnect failed connections which wa…

Though in JS an EventSource does automatically try to reconnect once it notices the connection is dropped, unlike a WebSocket.

It's not good enough in our experience, EventSource can still think it's connected when the server can no longer push data onto it. The periodic heartbeat to verify messages can still be sent on the connection is the only reliable way we've found to detect & autoretry failed connections.

Re: Server-Sent Events: an alternative to WebSockets

#257

Post by julianlam »

shahinghasemi wrote: post #153
julianlam wrote: post #108

This is really interesting! I wonder why it never really took off, whereas websockets via Socket.IO/Engine.io did. At NodeBB, we ended up relying on websockets for almost everything, which was a mistake. We were using it for simple call-and-response actions, where a proper RESTful API would've been a better (more scalable, better supported, etc.) solution. In the end, we migrated a large part of our existing socket.i…

> At NodeBB, we ended up relying on websockets for almost everything, which was a mistake. Would you please elaborate on the challenges/disadvantages you've encountered in comparison to REST/HTTP?

Nothing major, just browser support at the beginning, reverse proxy support (which is no longer an issue), but the big one was extensibility.

As it turns out, while almost anyone can fire off a POST request, not many people know how to wire up a socket.io client.

Re: Server-Sent Events: an alternative to WebSockets

#258

Post by bullen »

account42 wrote: post #246
smashah wrote: post #185

Earlier quoted context omitted.

Love your hybrid model via gumroad! I do something similar for my own open-source project https://github.com/open-wa/wa-automate-nodejs There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!

> open source projects Your source-available projects. Nothing wrong with licensing your work that way (in the sense that you can make that choice, not in the sense that I think its a good idea) but please don't muddle the term "open source".

Well technically rupy is open-source (ALGPL, yet another license that still doesn't exist) and since fuse (source-available) is built on top, you can maybe call it open-source, specially since rupy is like 90% of the code.

Re: Server-Sent Events: an alternative to WebSockets

#259

Post by yencabulator »

88913527 wrote: post #97
szastamasta wrote: post #33

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers. Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream): https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s... [0]: https…

SSE comes from a time when browser APIs toward Javascript forced a full download of the response body before it was handed to the Javascript.

With current day APIs, including streaming response bodies in the fetch API, SSE would probably not have been standardized as a separate browser API.

Re: Server-Sent Events: an alternative to WebSockets

#260

Post by smashah »

account42 wrote: post #246
smashah wrote: post #185

Earlier quoted context omitted.

Love your hybrid model via gumroad! I do something similar for my own open-source project https://github.com/open-wa/wa-automate-nodejs There should be some sort of support group for those of us trying to monetize (sans donations) our open source projects!

> open source projects Your source-available projects. Nothing wrong with licensing your work that way (in the sense that you can make that choice, not in the sense that I think its a good idea) but please don't muddle the term "open source".

Thanks for your input I will still continue to use whatever phrasing I see fit :)
Post reply on HN