A few years ago I was more inclined to use WebSockets. They're undeniably cool. But as implemented in browsers (thanks to the asynchronous nature of JavaScript)

A few years ago I was more inclined to use WebSockets. They're undeniably cool. But as implemented in browsers (thanks to the asynchronous nature of JavaScript) they offer no mechanism for backpressure, and it's pretty trivial to freeze both Chrome and Firefox sending in a loop if you have a fast upload connection. I designed a small protocol[0] to solve this (and a few other handy features) which we use at work[1]. A more robust option to solve similar problems is RSocket[3]. More recently I've been working on a reverse proxy[2], and realized how much of a special case WebSockets is to implement. Maybe I'm just lazy and don't want to implement WS in boringproxy, but these days I advocate using plain HTTP whenever you can get away with it. Server Sent Events on HTTP/1.1 is hamstrung by the browser connection limit, but HTTP/2 solves this, and HTTP/3 solves HTTP/2's head of line blocking problems. Also, as mentioned in the article, I try to prefer polling. This was discussed recently on HN[4]. [0]: https://github.com/omnistreams https://github.com/omnistreams [1]: https://iobio.io/2019/06/12/introducing-fibridge/ https://iobio.io/2019/06/12/introducing-fibridge/ [2]: https://boringproxy.io/ https://boringproxy.io/ [3]: https://rsocket.io/ https://rsocket.io/ [4]: https://news.ycombinator.com/item?id=27823109 https://news.ycombinator.com/item?id=27823109