[xg15]

Maybe it's a matter of perspective, but I don't understand why websockets are seen as super complex and error-prone, while long polling is supposed to be simple and elegant. Both are long-lived connections, where the client connects but the server pushes data. Where is the difference?

As for webhooks, my impression was that the main advantage was for the sender, not the receiver, because they don't have to deal with thousands of long-lived connections anymore.

My suspicion is that the big names who introduced webhooks first were quite aware of the potential downsides for reveivers but found them acceptable. (See e.g. twitter switching from a websocket-like "firehose" to webhooks)

If that was the case, then neither websockets nor (long) polling will be a viable replacement for webhooks because senders won't adopt it.

[anderspitman]

My main issue with WebSockets in terms of complexity comes on the server side, specifically with Upgrade being a hop-by-hop header, it's a bit of a pain to implement as a proxy, and I still haven't implemented WS support in boringproxy for this reason. Whereas polling using the same plumbing as everything else. Even server sent events are essentially just HTTP, though they're crippled with HTTP/1.1 and limited to text data.

But most people never need to implement an HTTP proxy. On the client side it's less of an issue, except it usually entails adding a dependency to your project unless you're using browser JavaScript.

For large services, I could see maintaining many open WebSockets becoming an issue, whereas with polling you can rate limit clients fairly easily to control the number of open connections you have.