> why to have thousands of connections instead of a single one (or a bunch) that simply forwards websocket packets with some "connection id"

For anyone wanting to do this sort of thing, check out Pushpin [1]. It's a proxy server that can manage raw WebSocket connections on behalf of any HTTP backend. There are middleware libraries (such as [2]) to make it easy to write handler code.

Disclosure: lead dev. Came up with the idea after developing a custom connection manager thing at a previous company.

[1] https://pushpin.org [2] https://github.com/fanout/js-serve-grip/blob/master/examples...

If I remember right, Slack's main application was PHP, now Hack, based, so I wouldn't be surprised to hear that app doesn't hold onto websocket connections itself - long-lived connections aren't historically PHP's wheelhouse

I didn't know anyone outside of Facebook used Hack! TIL.

https://www.youtube.com/watch?v=nPMI1uSrS8g here is a video of one of Slack's lead engineer discussing their migration from php --> hack

Slack has a Java server managing real-time messaging: https://www.quora.com/What-is-the-tech-stack-behind-Slack

“This part of our back-end, responsible for most of the real-time interactions happening in various clients, is implemented in Java, and accessed via a WebSocket API described here: Real Time Messaging API. A great deal of the user experience that makes Slack feel like Slack is the result of careful work on the message server. Many of the distributed systems challenges we face on the back-end are in coordinating this service with the rest of the (LAMP-ier) back-end.”

You could do that. But it would introduce a lot of head of line blocking on that connection. In return you Save a TLS handshake which might not be too important for long lived connections.

Plus it requires the backend to support that custom multiplexing layer.

How so? Why there should be a head of line blocking? This would be a simple multiplexing of the payloads.

If there on the other connection a lot of messages are exchanged (and a websocket frame could be gigabytes long according to the spec) the other stream would be blocked behind that.Of course that can be mitigated by using a non websocket framing, but that in the end reinvents yet another transport layer.

If you're looking to do this, I recommend the Nchan module for Nginx.