[mstade]

This seems like a terrible fit for WS. It's not a realtime problem, and doesn't require a realtime solution. Near-realtime will do just fine. I.e. have some endpoint that gives you voting results, and if requested with the text/event-stream media type will give you a stream of realtime events. Then post votes and what not with usual HTTP methods. This is presumably less efficient in terms of transport, but much more straight forward (and thus more cost-efficient) to implement and has some serendipitous side-effects such as your API now being usable by any ol' HTTP client.

Edit: to be clear, I'm agreeing with your assessment; and criticizing the article you linked to. :o)

[jacobolus]

If you are getting the results as an event stream, that doesn’t really save anything on client-side resources. Seems just as “real time”, just with a slightly different back-end implementation.

[mstade]

The difference is on the client-to-server communication, since it's a one-way stream. So you're right in saying it's just as realtime when getting results from the server, but there's added latency to each request being made from the client. My point is that this latency is probably negligible for most "realtime" applications. The benefit to all this is that you're not re-inventing protocols on top of a low-level transport, and both front- and backend becomes significantly simpler (and thus more cost effective) to implement.