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

Server-sent events

developer.mozilla.org

Post reply on HN
Print view View original

31–40 of 111 posts

Re: Server-sent events

#31

Post by flaviut »

kreetx wrote: post #28

Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...

I've never worked with Web Workers, but the doc page mentions them at the very top. Isn't that the intended workaround? Have a background thread that receives the events & coordinates, rather than having each page deal with them?

Re: Server-sent events

#32

Post by lecarore »

davidw wrote: post #10

How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?

I use this at work (Enterprise SAAS web software) and we had to implement a backup "polling every 5 seconds" for clients that would not support it. It's quite rare though. We assume that some caching proxy might be waiting for the GET request to be fully done to cache it and then give it to the user or something like this. The SSE would then never get updates, while every normal HTTP request would work

Re: Server-sent events

#33

Post by hamandcheese »

VWWHFSfQ wrote: post #15
marcellus23 wrote: post #12

Earlier quoted context omitted.

What was the challenge in typing indicators? My naive idea is that it's basically sending `typing_started` and `typing_ended` messages.

I'm guessing that since it's not a full-duplex connection you have to send those messages out-of-band, ie, with a separate POST request API

But messages themselves are already sent out-of-band as a POST request, if I understand correctly. Don't see why that couldn't be extended to include typing indicators.

Re: Server-sent events

#34

Post by silverwind »

flaviut wrote: post #31
kreetx wrote: post #28

Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...

I've never worked with Web Workers, but the doc page mentions them at the very top. Isn't that the intended workaround? Have a background thread that receives the events & coordinates, rather than having each page deal with them?

Yes, that's `ShardedWorker`.

Re: Server-sent events

#35

Post by Mogzol »

davidw wrote: post #10

How well do these work out in practice across a variety of platforms, behind firewalls, on phones, and so on?

They're well supported on modern browsers, both mobile and desktop. If you need to support IE then you can use a polyfill. It's essentially just a long-running HTTP request. The main issue I've run into before is if your server has a response timeout configured then you'll need to disable or work around it, otherwise it will disrupt the event stream whenever the timeout is hit, since the event stream is just an HTTP response.

Re: Server-sent events

#36

Post by jraph »

pieter wrote: post #13

Note that this really isn’t anything except the agreement to send messages separated by 2 new lines. The SSE object in browsers is old and quirky; for example, it only supports GET requests, which means you’ll hit path length limits if you use it for something like LLM completion with large prompts. Luckily since there’s nothing special about the browser support, you can very easily replace it with custom implementat…

There is this agreement, and also the fact that browsers can forget previous messages, unlike any xhr-based custom implementation since the EventSource object does not provide methods to access previous contents. I don't know how well this package handles this.

I agree with the note about the auto retry mechanism of EventSource. It does no good, is unavoidable and a big annoyance. The work we had to do to work around it in Tracim (previous job) [1] was pure madness. I see this part has not been touched since I left by the way.

https://github.com/tracim/tracim/blob/develop/frontend_lib/s...

Re: Server-sent events

#37

Post by twic »

no_wizard wrote: post #2

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 can open 6 SSE connections across all of the tabs to www.example1.com and another 6 SSE connections to www.example2.com. (from Stackoverflow). When using HTTP/2, the maximum number of simultaneous HTTP streams is negotiated between the server and the client (defaults to 100).

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!

It's also quite natural, i think, to want to use multiple separate streams. It's very convenient to write separate endpoints for various kinds of data that a page might want, for example one for streaming numerical data, one for control messages, and one for descriptive events; or one for each panel on a dashboard. Here, you can hit the limit on a single page.

I wrote a thin layer over my HTTP server's APIs which lets me write a single handler which can send events via either SSE or a websocket. Then, when i build a page, i use websockets, but if i want to debug, i can still use curl to make a normal HTTP request. Also, other apps can use SSE to pull data, which only requires an HTTP client, not a websocket client.

[1] https://developer.mozilla.org/en-US/docs/Web/API/EventSource

Re: Server-sent events

#38

Post by toomim »

kreetx wrote: post #28

Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...

This problem is fixed by using HTTP/2.

Re: Server-sent events

#39

Post by paulddraper »

VWWHFSfQ wrote: post #30
kreetx wrote: post #28

Server Sent Events infamously have low global connection limit per origin[1], so if you have multiple tabs open for a single site you'll run into it pretty quickly. If it weren't for that, they would be great. [1] https://stackoverflow.com/questions/18584525/server-sent-eve...

Sophisticated services that offer SSE will have many different endpoint domains to get around browser limits on simultaneous connections to the same service. endpoint-00.example.com endpoint-01.example.com endpoint-02.example.com etc. It isn't specific to SSE. It's any HTTP request. SSE is just the most obvious because the connections stay open for long periods.

And that's an easy workaround, with wildcard DNS entries and certs.

Re: Server-sent events

#40

Post by patwolf »

I did a web app project with SSEs a while back. They worked well in the browser, but when it came time to build a mobile app (React Native), I had trouble finding a good library to use. I'm sure I could have rolled my own, but being in a time crunch I ended up using Firebase Cloud Messaging. Hopefully there's better support these days.
Post reply on HN