5 ms·

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better.

My experience with sse is pretty bad. They are unreliable, don’t support headers and require keep-alive hackery. In my experience WebSockets are so much better. Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse.

tekknik 5y ago
> Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse. You can also implement websockets in 5 lines (less, really 1-3 for a basic implementation) without socket.ii. Why are you still using it?
mikojan 5y ago
What? How do they not support headers? You have to send "Content-Type: text/event-stream" just to make them work. And you keep the connection alive by sending "Connection: keep-alive" as well. I've never had any issues using SSEs.
- szastamasta 5y ago
  I mean you cannot send stuff from client. If you’re using tokens for auth and don’t want to use session cookies, you end with ugly polyfils.
  - coder543 5y ago
    > If you’re using tokens for auth and don’t want to use session cookies That sounds like a self-inflicted problem. Even if you’re using tokens, why not store them in a session cookie marked with SameSite=strict, httpOnly, and secure? Seems like it would make everything simpler, unless you’re trying to build some kind of cross-site widget, I guess.
    - szastamasta 5y ago
      I need to work with more than 1 backend :)
      - coder543 5y ago
        This is such an opaque response, I don't know what else could be said. If you're sending the same token to multiple websites, something feels very wrong with that situation. If it's all the same website, you can have multiple backends "mounted" on different paths, and that won't cause any problems with a SameSite cookie.
        szastamasta 5y ago
        Then you need a single point of failure that is handling session validation. Without it part of your app might work even without your sessions storage.
        coder543 5y ago
        You can store a JWT in a session cookie. You don’t need a SPoF for session validation, if that’s not what you want.
- JeanMeche 5y ago
  SSE won't work with tokens, see https://stackoverflow.com/questions/28176933/http-authorization-header-in-eventsource-server-sent-events https://stackoverflow.com/questions/28176933/http-authorizat...
jFriedensreich 5y ago
sounds like you did not really evaluate both technologies at the heart but only some libraries on top?
- szastamasta 5y ago
  Yeah, sorry. In socket.io it’s 2 lines. You need 5 lines with browser APIs :). You simply get stuff like auto-reconnect and graceful failover to long polling for free when using socket.io
  - tekknik 5y ago
    2 lines vs 5 lines. did you check your payload size after adding socket.io? you added way more than 2 lines. long polling shouldn’t be needed anymore, and auto reconnect is trivial to implement.
  - coder543 5y ago
    SSE EventSource also has built-in auto-reconnect, and it doesn’t even need to support failover to long polling. Neither of those being built into a third party websocket library are actually advantages for websocket… they just speak to the additional complexity of websocket. Plus, long polling as a fallback mechanism can only be possible with server side support for both long polling and websocket. Might as well just use SSE at that point.
bullen 5y ago
They don't support headers in javascript, that is more a problem with javascript than SSE. Read my comment below about that.
ricardobeat 5y ago
Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.
- dnautics 5y ago
  I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.
  - bullen 5y ago
    Not if you send "noop" messages.
    - dnautics 5y ago
      In my experience, sse times out way more than ws, even if you are always sending (I was streaming jpegs using sse).
      - bullen 5y ago
        I think it might be your ISP. For example one of my ISPs cut off my SSH connections no matter what I do. They simply dislike hanging SSH connections. It's just random that your ISP like WebSockets more than long HTTP responses, and it can change in a heartbeat and for most people it will be different. As I said before 99,6% successful networking is an unheard of number for real-time multiplayer games. I only care about that number, until you proove with hard stats and 350.000 real users from everywhere on the planet that WebSocket has 99,7% success rate, I'm not even going to flinch.
        dnautics 5y ago
        It's not random. Having limited timeouts for http is policy set at often time several layers to prevent certain types of security regressions.
88913527 5y ago
HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers. Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream): https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-server-js-L25-L29 https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s... [0]: https://en.wikipedia.org/wiki/Chunked_transfer_encoding https://en.wikipedia.org/wiki/Chunked_transfer_encoding
- yencabulator 5y ago
  SSE comes from a time when browser APIs toward Javascript forced a full download of the response body before it was handed to the Javascript. With current day APIs, including streaming response bodies in the fetch API, SSE would probably not have been standardized as a separate browser API.
- patrickthebold 5y ago
  Maybe I misunderstood your claim, but there is: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr... Which seems to be what you need to send 'headers' after a chunked response.
  - 88913527 5y ago
    You understood correctly; I was mis-informed. Today I learned about the "Trailer" header. I'm curious how HTTP clients handle that. A client like window.fetch will resolve with a headers object-- does it include the trailers or not? I'd have to test it out.
- tehbeard 5y ago
  More so the issue is the "native" browser client, EventSource [1] is pretty much just url and "withCredentials" (send/don't send cookies) You can kludge it with fetch(...) and the body stream 1. <https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource>
pier25 5y ago
WebSockets are also quite unreliable but Socket IO hides all this from you.
- tekknik 5y ago
  socket.io doesn’t do as much as the bloat warrants. implementing the same features (heartbeats and reconnects) takes minimal code. socket.io was useful when certain browsers didn’t support websockets, now it’s used mostly by people scared of sockets imo

tekknik 5y ago

> Also ease of use doesn’t really convince me. It’s like 5 lines of code with socket.io to have working websockets, without all the downsides of sse. You can also implement websockets in 5 lines (less, really 1-3 for a basic implementation) without socket.ii. Why are you still using it?

mikojan 5y ago

What? How do they not support headers? You have to send "Content-Type: text/event-stream" just to make them work. And you keep the connection alive by sending "Connection: keep-alive" as well. I've never had any issues using SSEs.

szastamasta 5y ago
I mean you cannot send stuff from client. If you’re using tokens for auth and don’t want to use session cookies, you end with ugly polyfils.
- coder543 5y ago
  > If you’re using tokens for auth and don’t want to use session cookies That sounds like a self-inflicted problem. Even if you’re using tokens, why not store them in a session cookie marked with SameSite=strict, httpOnly, and secure? Seems like it would make everything simpler, unless you’re trying to build some kind of cross-site widget, I guess.
  - szastamasta 5y ago
    I need to work with more than 1 backend :)
    - coder543 5y ago
      This is such an opaque response, I don't know what else could be said. If you're sending the same token to multiple websites, something feels very wrong with that situation. If it's all the same website, you can have multiple backends "mounted" on different paths, and that won't cause any problems with a SameSite cookie.
      - szastamasta 5y ago
        Then you need a single point of failure that is handling session validation. Without it part of your app might work even without your sessions storage.
        coder543 5y ago
        You can store a JWT in a session cookie. You don’t need a SPoF for session validation, if that’s not what you want.
JeanMeche 5y ago
SSE won't work with tokens, see https://stackoverflow.com/questions/28176933/http-authorization-header-in-eventsource-server-sent-events https://stackoverflow.com/questions/28176933/http-authorizat...

jFriedensreich 5y ago

sounds like you did not really evaluate both technologies at the heart but only some libraries on top?

szastamasta 5y ago
Yeah, sorry. In socket.io it’s 2 lines. You need 5 lines with browser APIs :). You simply get stuff like auto-reconnect and graceful failover to long polling for free when using socket.io
- tekknik 5y ago
  2 lines vs 5 lines. did you check your payload size after adding socket.io? you added way more than 2 lines. long polling shouldn’t be needed anymore, and auto reconnect is trivial to implement.
- coder543 5y ago
  SSE EventSource also has built-in auto-reconnect, and it doesn’t even need to support failover to long polling. Neither of those being built into a third party websocket library are actually advantages for websocket… they just speak to the additional complexity of websocket. Plus, long polling as a fallback mechanism can only be possible with server side support for both long polling and websocket. Might as well just use SSE at that point.

bullen 5y ago

They don't support headers in javascript, that is more a problem with javascript than SSE. Read my comment below about that.

ricardobeat 5y ago

Mind expanding on your experience and how are websockets more reliable than SSE? one of the main benefits of SSE is reliability from running on plain HTTP.

dnautics 5y ago
I've done both. One big one is Sse connections will eventually time out, and you WILL have to renegotiate, so there will be a huge latency spike on those events. They are easier in elixir than most pls, but honestly if you're using elixir, you might as well use phoenix's builtin we socket support.
- bullen 5y ago
  Not if you send "noop" messages.
  - dnautics 5y ago
    In my experience, sse times out way more than ws, even if you are always sending (I was streaming jpegs using sse).
    - bullen 5y ago
      I think it might be your ISP. For example one of my ISPs cut off my SSH connections no matter what I do. They simply dislike hanging SSH connections. It's just random that your ISP like WebSockets more than long HTTP responses, and it can change in a heartbeat and for most people it will be different. As I said before 99,6% successful networking is an unheard of number for real-time multiplayer games. I only care about that number, until you proove with hard stats and 350.000 real users from everywhere on the planet that WebSocket has 99,7% success rate, I'm not even going to flinch.
      - dnautics 5y ago
        It's not random. Having limited timeouts for http is policy set at often time several layers to prevent certain types of security regressions.

88913527 5y ago

HTTP headers must be written before the body; so once you start writing the body, you can't switch back to writing headers. Server-sent events appears to me to just be chunked transfer encoding [0], with the data structured in a particular way (at least from the perspective of the server) in this reference implementation (tl,dr it's a stream): https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-server-js-L25-L29 https://gist.github.com/jareware/aae9748a1873ef8a91e5#file-s... [0]: https://en.wikipedia.org/wiki/Chunked_transfer_encoding https://en.wikipedia.org/wiki/Chunked_transfer_encoding

yencabulator 5y ago
SSE comes from a time when browser APIs toward Javascript forced a full download of the response body before it was handed to the Javascript. With current day APIs, including streaming response bodies in the fetch API, SSE would probably not have been standardized as a separate browser API.
patrickthebold 5y ago
Maybe I misunderstood your claim, but there is: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Tr... Which seems to be what you need to send 'headers' after a chunked response.
- 88913527 5y ago
  You understood correctly; I was mis-informed. Today I learned about the "Trailer" header. I'm curious how HTTP clients handle that. A client like window.fetch will resolve with a headers object-- does it include the trailers or not? I'd have to test it out.
tehbeard 5y ago
More so the issue is the "native" browser client, EventSource [1] is pretty much just url and "withCredentials" (send/don't send cookies) You can kludge it with fetch(...) and the body stream 1. <https://developer.mozilla.org/en-US/docs/Web/API/EventSource https://developer.mozilla.org/en-US/docs/Web/API/EventSource>

pier25 5y ago

WebSockets are also quite unreliable but Socket IO hides all this from you.

tekknik 5y ago
socket.io doesn’t do as much as the bloat warrants. implementing the same features (heartbeats and reconnects) takes minimal code. socket.io was useful when certain browsers didn’t support websockets, now it’s used mostly by people scared of sockets imo