2 ms·
> more of a tradeoff You make it sound like it would have taken months of investment to just use one of the many available better options - at worst, it might
by commandlinefan 7y ago
> more of a tradeoff
You make it sound like it would have taken months of investment to just use one of the many available better options - at worst, it might have taken a week for somebody to learn web sockets if they actually didn’t have anybody who knew it (and even then, that’s a slow learner). We should be delivering the most efficient options and always weighing the alternatives - we’re professionals, maybe some day we’ll actually start behaving that way. From the top-level responses to this article, today is not that day.
- spenczar5 7y agoWebsockets imply persistent connections between servers and clients. That long-term state tightly couples the two: deploying a change to servers now requires draining all running connections, for example. Load balancing is much harder. Throttling client behavior is much harder, so you’re not as insulated from bad client behavior or heavy hitters. Consequences of that decision ripple through the entire architecture. I really like the polling approach used here. It’s simple, easy to reason about, and loosely coupled. It will be reliable and resilient. Saying it might have taken a week to learn websockets completely misses the point. I’ve built large architectures on persistent connections and deeply regretted it.
- tjungblut 7y agoExactly! Keeping all of those stateful connections open is a much bigger issue than loadbalancing simple HTTP polls (that you could cache super aggressively). I think this is what this blog post really misses and shows that they have not much of a clue how to operate things at a worldwide scale.