[HN Gopher] Server-Sent Events (SSE) Are Underrated
___________________________________________________________________
Server-Sent Events (SSE) Are Underrated
Author : Igor_Wiwi
Score : 47 points
Date : 2024-12-25 21:35 UTC (1 hours ago)
(HTM) web link (igorstechnoclub.com)
(TXT) w3m dump (igorstechnoclub.com)
| recursivedoubts wrote:
| https://data-star.dev is a hypermedia-oriented front end library
| built entirely around the idea of streaming hypermedia responses
| via SSE.
|
| It was developed using Go & NATS as backend technologies, but
| works with any SSE implementation.
|
| Worth checking out if you want to explore SSE and what can be
| achieved w/it more deeply. Here is an interview with the author:
|
| https://www.youtube.com/watch?v=HbTFlUqELVc
| ramon156 wrote:
| They're underrated when they work(tm)
|
| Currently at work I'm having issues because - Auth between an
| embedded app and javascript's EventSource is not working, so I
| have to resort to a Microsoft package which doesn't always work.
| - Not every tunnel is fond of keep-alive (Cloudflare), so I had
| to switch to ngrok (until I found out they have a limit of 20k
| requests).
|
| I know this isn't the protocol's fault, and I'm sure there's
| something I'm missing, but my god is it frustrating.
| condiment wrote:
| So it's websockets, only instead of the Web server needing to
| handle the protocol upgrade, you just piggyback on HTTP with an
| in-band protocol.
|
| I'm not sure this makes sense in 2024. Pretty much every web
| server supports websockets at this point, and so do all of the
| browsers. You can easily impose the constraint on your code that
| communication through a websocket is mono-directional. And the
| capability to broadcast a message to all subscribers is going to
| be deceptively complex, no matter how you broadcast it.
| realPubkey wrote:
| Yes most servers support websockets. But unfortunately most
| proxies and firewalls do not, especially in big company
| networks. Suggesting my users to use SSEs for my database
| replication stream solved most of their problems. Also setting
| up a SSE endpoint is like 5 lines of code. WebSockets instead
| require much more and you also have to do things like pings etc
| to ensure that it automatically reconnects. SEEs with the
| JavaScript EventSource API have all you need build in:
|
| https://rxdb.info/articles/websockets-sse-polling-webrtc-web...
| the_mitsuhiko wrote:
| SSE also works well on HTTP/3 whereas web sockets still
| don't.
| apitman wrote:
| I don't see much point in WebSockets for HTTP/3.
| WebTransport will cover everything you would need it for an
| more.
| programmarchy wrote:
| Great post. I discovered SSE when building a chatbot and found
| out it's what OpenAI used rather than WebSockets. The batteries-
| included automatic reconnection is huge, and the format is
| surprisingly human readable.
| dugmartin wrote:
| It doesn't mention the big drawback of SSE as spelled out in the
| MDN docs:
|
| "Warning: When not used over HTTP/2, SSE suffers from a
| limitation to the maximum number of open connections, which can
| be especially painful when opening multiple tabs, as the limit is
| per browser and is set to a very low number (6)."
| k__ wrote:
| And over HTTP/2 and 3 they are efficient?
| apitman wrote:
| HTTP/2+ only uses a single transport connection (TCP or QUIC)
| per server, and multiplexes over that. So there's essentially
| no practical limit.
| RadiozRadioz wrote:
| That is a very low number. I can think of many reasons why one
| would end up with more. Does anyone know why it is so low?
| apitman wrote:
| > Perceived Limitations: The unidirectional nature might seem
| restrictive, though it's often sufficient for many use cases
|
| For my use cases the main limitations of SSE are:
|
| 1. Text-only, so if you want to do binary you need to do
| something like base64
|
| 2. Browser connection limits for HTTP/1.1, ie you can only have
| ~6 connections per domain[0]
|
| Connection limits aren't a problem as long as you use HTTP/2+.
|
| Even so, I don't think I would reach for SSE these days. For less
| latency-sensitive and data-use sensitive applications, I would
| just use long polling.
|
| For things that are more performance-sensitive, I would probably
| use fetch with ReadableStream body responses. On the server side
| I would prefix each message with a 32bit integer (or maybe a
| variable length int of some sort) that gives the size of the
| message. This is far more flexible (by allowing binary data), and
| has less overhead compared to SSE, which requires 7 bytes
| ("data:" + "\n\n") of overhead for each message.
|
| [0]: https://stackoverflow.com/a/985704
| kdunglas wrote:
| A while ago I created Mercure: an open pub-sub protocol built on
| top of SSE that is a replacement for WebSockets-based solutions
| such as Pusher. Mercure is now used by hundreds of apps in
| production.
|
| At the core of Mercure is the hub. It is a standalone component
| that maintains persistent SSE (HTTP) connections to the clients,
| and it exposes a very simple HTTP API that server apps and
| clients can use to publish. POSTed updates are broadcasted to all
| connected clients using SSE. This makes SSE usable even with
| technologies not able to maintain persistent connections such as
| PHP and many serverless providers.
|
| Mercure also adds nice features to SSE such as a JWT-based
| authorization mechanism, the ability to subscribe to several
| topics using a single connection, events history, automatic state
| reconciliation in case of network issue...
|
| I maintain an open-source hub written in Go (technically, a
| module for the Caddy web server) and a SaaS version is also
| available.
|
| Docs and code are available on https://mercure.rocks
| piccirello wrote:
| I utilized SSE when building automatic restart functionality[0]
| into Doppler's CLI. Our api server would send down an event
| whenever an application's secrets changed. The CLI would then
| fetch the latest secrets to inject into the application process.
| (I opted not to directly send the changed secrets via SSE as that
| would necessitate rechecking the access token that was used to
| establish the connection, lest we send changed secrets to a
| recently deauthorized client). I chose SSE over websockets
| because the latter required pulling in additional dependencies
| into our Golang application, and we truly only needed
| server->client communication. One issue we ran into that hasn't
| been discussed is HTTP timeouts. Some load balancers close an
| HTTP connection after a certain timeout (e.g. 1 hour) to prevent
| connection exhaustion. You can usually extend this timeout, but
| it has to be explicitly configured. We also found that our server
| had to send intermittent "ping" events to prevent either
| Cloudflare or Google Cloud Load Balancing from closing the
| connection, though I don't remember how frequently these were
| sent. Otherwise, SSE worked great for our use case.
|
| [0] https://docs.doppler.com/docs/automatic-restart
| yu3zhou4 wrote:
| I've had no idea they exist until I began to use APIs serving LLM
| outputs. They work pretty well for this purpose from my
| experience. An alternative to SSE is web sockets for this purpose
| I suppose
___________________________________________________________________
(page generated 2024-12-25 23:00 UTC)