3 ms·
All that speaks to the point that the underlying protocol does not matter that much. The larger design is a more important consideration than the specific push
by jallmann 3y ago
All that speaks to the point that the underlying protocol does not matter that much. The larger design is a more important consideration than the specific push tech.
None of this favors SSE, or anything else for that matter. You still have to think about bursting / thundering herd behavior after server restarts, which would affect any protocol. The browser auto reconnecting doesn't mean you can assume the connection remains alive indefinitely if a reconnect hasn't happened; you may want periodic notifications as a keepalive to enable more immediate recovery. Long-lived server state introduces its own distributed coordination and cleanup problems, which strict request-reply polling sidesteps entirely. Etc.
There is no silver bullet, only tradeoffs in the design space that need to be matched to your application's requirements.
- akira2501 3y ago> the underlying protocol does not matter that much Then why is long polling the "clear winner?"
- jallmann 3y agoFor interoperability with HTTP tooling (eg, curl) it is the clear winner
- akira2501 3y agoSSE, which is just an HTTP request, works perfectly fine with curl or any other library which makes HTTP requests.
- jallmann 3y agoCurl and most libraries don't unwrap SSE for you out of the box, you lose the one-shot request-response leading to nonstandard flow control in integrations, etc. Sure you can find random libraries to help but they do need to be specifically built for SSE. Plain (long-)polling does not need any of that, which makes it more attractive from an API interoperability standpoint.