The 68KiB per 5 minutes is trivial for most users and the 10 second latency for a sports score usually is too. Measure fixing these problems against the opportunity cost of not getting something else done. This reads as more of a tradeoff than a horror story.
Moreover it might not just be developer time vs. latency that's being traded off.
Maintaining a stateful websocket connection on the server side isn't cost-free, and that connection would be idle nearly 100% of the time. The bandwidth consumed via Google's polling solution might well be cheaper than open socket file descriptors of a websockets solution.
Moreover, if they are concerned about bandwidth they could definitely transmit these data with less than the ~2.2KB/request it’s taking. Fixed width integers, anyone? No parsing overhead, even. And that’s without getting fancy. Maybe some flags to indicate a full refresh needed if e.g. a match has ended. 2.2kb must include markup or something.
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.
Websockets 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.
Exactly! 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.
