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.
OpenAI uses this in their APIs to stream tokens
Server-sent events
21–30 of 111 posts
Re: Server-sent events
#22SSE 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.
Re: Server-sent events
#23I 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…
Slack does use websocket for “someone is typing” event: https://slack.engineering/real-time-messaging/
Re: Server-sent events
#24ChatGPT uses SSE to stream the AI's responses, token-by-token!
Re: Server-sent events
#25Curious 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.
Probably as a result of https://news.ycombinator.com/item?id=35937554
My first thought was ChatGPT API's `stream` option: https://platform.openai.com/docs/api-reference/completions/c...
Re: Server-sent events
#26I was looking through the implementation of chat.openai.com recently and was pleasantly surprised to see that it was 100% Server Sent Events, no Websockets.
SSE is a great tool to have in your belt. I'd say it can replace the majority of use cases for Websockets out there today (basically pushing small amounts of text/JSON data to the client) with a tiny fraction of the complexity. Opening and maintaining a bidirectional TCP stream is otherwise a huge pain in the ass.
Re: Server-sent events
#27I 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…
What was the challenge in typing indicators? My naive idea is that it's basically sending `typing_started` and `typing_ended` messages.
You can skip the "typing ended". You're gonna need a shortish timeout anyway, may as well just let the "typing is happening" messages all terminate by timeout.
Re: Server-sent events
#28Server 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...
Re: Server-sent events
#29SSE are amazing!
I've used them to push updates to clients from multiple goroutines (Go threads) with https://lastfm.live
It's quite simple to start with on the Go backend side of things and the frontend things aren't too complicated either.
Re: Server-sent events
#30Server 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.