4 ms·
Depending on what you are trying to achieve, I also recommend SSE over websockets, especially if all you want is to signal clients when state changes on the ser
by tored 5y ago
Depending on what you are trying to achieve, I also recommend SSE over websockets, especially if all you want is to signal clients when state changes on the server.
SSE is a simple protocol that you can easily implement yourself both in the server and the client if the client lacks support.
SSE also adds naturally to existing infrastructure of request-response if you only use SSE for notification and keep everything the same, i.e. use same endpoints as before for fetching new data on a SSE notification event, and thus can be turned off as easily if problematic, e.g. too high server load.
- klabb3 5y agoYeah I agree. But even though SSE is super easy to grok and to implement (literally just standardized long polling), lots of existing infra builds on the assumptions that connections are short lived, so many of the WS issues apply to SSE as well. IMHO, this unfortunate assumption is not really defensible in $current_year - especially from the multi billion dollar Cloud industry. I'd much more prefer first class support for long-lived connections on an infrastructure level, as opposed to a "proprietary database-level". I don't buy the argument that it's infeasible to solve the thundering herd issues.