3 ms·

> I'm gonna go out on a limb and say that head-of-line blocking is not what prevented wider adoption of Websockets. What do you think it was/is? (not disagreei

• klabb3 4y ago
  Primarily load balancers and other cloudy middleware stuff. Most existing infrastructure is built on the request-response model (for good and bad). Maintaining a long lived connection makes more sense in the traditional single-beefy-server world, but with lambdas, containers, reverse proxies and everything being transparent and ephemeral it was too big of a game changer for cloud providers, in particular PaaS, I think.
  • inhumantsar 4y ago
    100% this. Scaling websockets is fine if your app sees consistent load or don't mind paying for unused capacity. While it's certainly doable, it's disruptive to horizontally scale websockets servers and depending on how you use it, can result in significant amounts of duplicated data transfer. From cost and UX perspectives, it's just not worth it. Either use websockets and accept the fact that you'll always be paying for all the capacity you might need or give up and poll a low latency endpoint.
    • graderjs 4y ago
      Isn't a viable horizontal scale solution to have a central allocator, that assigns a new client to a pool instance that then has a direct websocket with the client? So there's no central choke point or "websocket load balancer that all frames flow through" That's how I've always done it for scalable deployments of my remote browser isolation service.