News for hackers. Stuff that matters.
Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by mmis1000 on Monday March 18, 2024 @02:02PM (#39747743)
SSE isn't really more complex than long polling. The only difference is the server don't close the connection immediately after sent the response. Instead, it wait for data again and send more response using the same stream.
Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by jallmann on Monday March 18, 2024 @03:16PM (#39748674)
Long polling is more amenable than SSE for most HTTP tools out of the box, eg curl. The SSE message body is notably different from plain HTTP responses.

To the OP, you can still build APIs with long polling. They are uncommon because push patterns are difficult to design well, regardless of protocol (whether long-polling, SSE, websockets, etc).

Whiteboarding a push API is a good exercise. There is a lot of nuance that gets overlooked in discussions whenever these patterns come up.

Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by kevmo314 on Monday March 18, 2024 @04:06PM (#39749311)
Well I know I can write applications use it, but I don't often write code outside the context of a team that has other opinions anymore :)
Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by apitman on Monday March 18, 2024 @03:42PM (#39749030)
One limitation of SSE compared to long polling (and WebSockets etc) is you can't efficiently send binary data such as cbor, protobuf, etc. Though if your long polling is chatty enough eventually the HTTP overhead will kill your efficiency too.
Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by niutech on Saturday March 23, 2024 @07:27AM (#39799121)
You can use binary-sse (https://github.com/luciopaiva/binary-sse) with minimal overhead.
Re:WebSockets vs. Server-Sent-Events vs. Long-Polling vs. We... by jacobr1 on Monday March 18, 2024 @03:10PM (#39748609)
Agreed - I see SSE as basically a standardized approach to modern long polling