9 comments

[ 3.1 ms ] story [ 30.3 ms ] thread
Interesting difference between Server-Sent Events and Websockets if the former can deliver out-of-order like UDP: "Because SSE works on top of HTTP, HTTP protocol improvements can also benefit SSE. For example, the in-development HTTP/3 protocol, built on top of QUIC, could offer additional performance improvements in the presence of packet loss due to lack of head-of-line blocking."
(comment deleted)
SSE can deliver out of order? Is that within a single EventSource or across multiple. I thought that within a single EventSource all messages were in order.
Good point and a downer if you need to hack with multiple EventSources. In any case, I see there's ongoing standardisation work on WebTransport including a DatagramTransport on top of QUIC: "It can be used like WebSockets but with support for multiple streams, unidirectional streams, out-of-order delivery, and reliable as well as unreliable transport." https://wicg.github.io/web-transport/#introduction
You mentioned Twitter uses server sent events. Do you have a link you car share about that? I'm interested in learning more about how they use SSE.
One case I've come across them using it for is delivering updates for visible tweets in a timeline (e.g. like/retweet counts being mutated).
> SSEs are sent over traditional HTTP. That means they do not require a special protocol or server implementation to get working.

Can you not combine your HTTP and WebSocket requests behind the same HTTP server/port in golang? Other languages I've used support that.