71–80 of 111 posts
Curious why is this trending? Btw sse are pretty great, only thing I don't get is why they don't allow for binary payloads. That'd have been the icing on the cake.
So also avoid HTTPS.
It's trending because it's the final real-time solution for eternity.
How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?
Real life stats: "759 out of 205.875 customers refunded because their antivirus blocks the pull HTTP stream", so 99.7%!
They even go through the great firewall without bureaucracy.
SSE is pretty good but I have never been able to see the messages in firefox devtools, and doesn't work with binary data. HTTP/2 streams are just as easy to implement, and work both ways and support binary data.
console.log or wireshark
SSE is phenomenal and underutilized because it wasn't supported by IE.
Be careful what you release because it might not be fixable after release.
Love to see stuff like this on the HN front page, when I know tons of web devs that have never even heard of SSE. Tangentially, I’m having a massive problem with SSE datastreams erroring out about two minutes in for “ERR: Network chunk encoding” reasons, anyone else seen this before?
In theory, a TCP session can remain alive forever. In practice, various things got in the way, and you need traffic to keep it alive (keep-alive, ping, heartbeat, it gets given various names). I believe once a minute should be enough. I’ve encountered "ping" and "" used as SSE event names for this purpose.
Earlier quoted context omitted.
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
> The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all! You can use EventSource in a singleton worker and use postMessage to forward messages to all open browser tabs for the same origin.
I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
Earlier quoted context omitted.
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
> It's also quite natural, i think, to want to use multiple separate streams. i dont think i'd call it natural per se - i'd say it's just "easy" to do so, and especially if each of these separate streams are managed by different teams, and it makes business sense to separate the responsibility. There should be a framework, perhaps, to allow "multiplexing" of multiple streams of events into one actual tcp connection.…
I know alot of websites and engineers use Websocket for push only data. SSE is tailored made for real time one sided updates! In fact, I think it made a better chat protocol, when we built a chat system at a previous job, similar to Slack. We ended up leveraging SSE to push updates to channels and traditional HTTP requests to send data to the server, resulting in lower latency and less overhead on the server side. We…
And why would latency be lower with HTTP requests + SSE than with websockets?
Earlier quoted context omitted.
The big problem i've run into with SSE is the connection limit [1]: > Warning: When not used over HTTP/2, SSE suffers from a limitation to the maximum number of open connections, which can be specially painful when opening various tabs as the limit is per browser and set to a very low number (6). The issue has been marked as "Won't fix" in Chrome and Firefox. This limit is per browser + domain, so that means that you…
> The natural way to use SSE is to create an EventSource on each page. If you do this, and your user opens six tabs, they can now no longer make HTTP requests to your site. Not just SSE requests, any HTTP requests at all! You can use EventSource in a singleton worker and use postMessage to forward messages to all open browser tabs for the same origin.
plus you now have to handle multiplexing and demultiplexing for different tabs on both server and client.
By the time that arrived and HTTP/2 had wide enough adoption, everyone's already used to building atop Websocket...
Also the EventSource in the browser is heavily gimped. GET only, No custom headers, and last I checked you can forget about configuring any CORS stuff for credential passing.