3 ms·

> Example: have a /events?fromTS=123 endpoint. This is what SSE (Server Side Events) is designed to do. A stripped down version of websockets which: - auto re

• jimmont 5y ago
  server-sent events (SSE) likely also improves battery life, more via https://developer.mozilla.org/docs/Web/API/Server-sent_events https://developer.mozilla.org/docs/Web/API/Server-sent_event... supported also: https://deno.land/x/oak@v5.2.0/docs/sse.md https://deno.land/x/oak@v5.2.0/docs/sse.md https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events https://html.spec.whatwg.org/multipage/server-sent-events.ht...
• aidenn0 5y ago
  I remember when I first heard about websockets, I was wondering what exactly it was useful for that SSE didn't already do. Almost all of the demos at the time were easier (IMO) to do with SSE. The two standards also both came from WHATWG at about the same time. [edit] I looked it up and SSE was a much earlier standard, but implementation of WS and SSE were relatively contemporary with the exception of Opera (had SSE in 2006) and IE (Never got SSE support).
  • klabb3 5y ago
    I didn't know that SSE came first, thanks for adding that context. It does feel like websockets tried to cram several novel features whereas SSE was simply giving proper clothing to the existing art of long polling. In particular, WS is binary encoded, has support for multiplexing/message splitting, several optional http headers, which in hindsight appears to have simply complicated the spec at little-to-nil value.
• 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 ago
    Yeah 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.
• winrid 5y ago
  SSE have a lot of restrictions that make them unattractive, like a global limit of 6 per browser session. This can cause confusing behavior for power users...
  • klabb3 5y ago
    Hm yeah now that you mention it I recall that as well. Isn't that just an arbitrary crippling though? I can't imagine a good reason for why SSE would be hogging more resources than websockets.