7 ms·

This is an astonishingly bad idea. Don't do this. Use HTTP server-sent events instead. Those can keep the connection open so you don't have to poll to get real

• montroser 1y ago
  Yeah, but in real life, SSE error events are not robust, so you still have to do manual heartbeat messages and tear down and reestablish the connection when the user changes networks, etc. In the end, long-polling with batched events is not actually all that different from SSE with ping/pong heartbeats, and with long-polling, you get the benefit of normal load balancing and other standard HTTP things
  • xyzzy_plugh 1y ago
    Correct. In the end, mechanically, nothing beats long polling. Everything ends up converging at which point you may as well just long poll.
  • mikojan 1y ago
    But SSE is a standard HTTP thing. Why would you not be able to do "normal load balancing"? I would also rather not have a handful of long-polling loops pollute the network tab.
    • jpc0 1y ago
      “Normal load balancing” means “Request A goes to server A”, “Request B goes to server B” and there is no state held in the server, if there is a session its stored in a KV store or database which persists. With SSE the server has to be stateful, for load balancing to work you need to be able to migrate connections between servers. Some proxies / load balancers don’t like long lasting connections and will tear them down if there has been no traffic so your need to constantly send a heart beat. I have deployed SSE, I love the technology, I wouldn’t deploy it if I don’t control the end devices and everything in between, I would just do long polling.
      • kiitos 1y ago
        Your description of "normal load balancing" is certainly one way to do load balancing, but in no way is it the presumptive default. Keeping session data in a shared source of truth like a KV store or DB, and expecting (stateless) application servers to do all their session stuff thru that single source of truth, is a fine approach for some use cases, but certainly not a general-purpose solution. > With SSE the server has to be stateful, for load balancing to work you need to be able to migrate connections between servers. Weird take. SSE is inherently stateful, sure, in the sense that it generally expects there to be a single long-lived connection between the client and the server, thru which events are emitted. Purpose of that being that it's a more efficient way to stream data from server to client -- for specific use cases -- than having the client long-poll on an endpoint.
        • jpc0 1y ago
          > Keeping session data in a shared source of truth like a KV store or DB, and expecting (stateless) application servers to do all their session stuff thru that single source of truth What would be a scalable alternative? Simple edge-case why this is a reasonable approach. Load balancer sends request to server A, server A sends response and goes offline, now load balancer has to send all request to server B->Z until server A comes back online. If the session data was stored on server A all users who were previously communicating to server A now lost their session data, probably reprompting a sign-in etc Theres some state you can store in a cookie, hopefully said state isn’t in any was mean to be trusted since rule 1 of web is you don’t trust the client. Simple case of a JWT for auth, you still need to validate the JWT is issued by you and hasn’t been invalidated, ie a DB lookup.
          • andersmurphy 1y ago
            This is the same with request response. You need to auth on each request (unless you use a cookie).
            • jpc0 1y ago
              Exactly that you use a cookie which stores an id to a session stored in the KV/DB. Moving the session data to a JWT stores some session data in the JWT but then you need to validate the JWT on each request which depending on your architecture might be less overhead but it still means you need some state stored in a KV/DB and it cannot be stored on server same as with a session, this might legitimately be less state, just a JWT id of some sort and whether it’s not revoke but it cannot exist on the server, it needs to be persistent.
  • andersmurphy 1y ago
    Never had to use ping/pong with SSE. The reconnect is reliable. What you probably had happen was your proxy or server return a 4XX or 5XX and that cancels the retry. Don't do that and you'll be fine. SSE works with normal load balancing the same as regular request/response. It's only stateful if you make your server stateful.
• toomim 1y ago
  Or use Braid-HTTP, which gives you both options. (Details in the previous thread on HTTP Feeds: https://news.ycombinator.com/item?id=30908492 https://news.ycombinator.com/item?id=30908492 )
• Alifatisk 1y ago
  Isn't SSE limited to like 12 tabs or something? I remember vividly reading about a huge limitation on that hard limit.
  • curzondax 1y ago
    6 tabs is the limit on SSE. In my opinion Server Sent Events as a concept is therefore not usable in real world scenarios as of this limitation or error-detection around that limitation. Just use Websockets instead.
    • tefkah 1y ago
      that's an http 1.1 only limitation. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events#listening_for_custom_events https://developer.mozilla.org/en-US/docs/Web/API/Server-sent...
      • Alifatisk 1y ago
        Ahhh
      • toomim 1y ago
        HTTP2 is limited to 100.
    • andersmurphy 1y ago
      This is a misinformed take. H2/H3 gives you 100+ connections. Even then you only need h2 from the proxy to the browser. If you have to use H1 for some reason you can easily prune connections with the browser visibility api.