<i>> Why does everyone run to websockets even when they only need server-to-client pushing? Probably because it's difficult to get longpolling right.</i><p>Definitely not. Longpolling adds a huge amount of overhead when messages are sent relatively frequently. For each longpoll request, the client needs to send all the headers and cookies every time. Each response includes all headers and connection setup. A websocket connection has zero overhead after the initial http upgrade. If you have websocket available, you should always prefer websocket to long polling. In most cases where websocket would be blocked by infrastructure, long polling would be forced to retry extremely quickly because of forced timeout.
Long polling is a hack. Anyone who has had to scale it across more than a single CPU core on a single machine will know this.<p>TCP and WebSockets are stateful, HTTP is stateless.
So long polling is essentially:<p>Stateful -> Stateless -> Sateful<p>You start in a good place, then you add complexity to make it stateless and then you add even more complexity to roll back the statelessness and then you end up where you started... Except it's 90% slower and you now have to use an armada of sticky load balancers to prevent the system from falling apart...
When I needed some simple push notifications, I could't find any decent library or example for longpolling in go (or most other languages), so I decided to make one :)<p>A lot of the examples out there in blog posts are too simplistic. They don't handle buffering old events and most of them simply give an event to the first request and then discard it. That's not real pub-sub.
Great to see this. I am a big fan of long-polling. Too many people only think of it as some hack underlying libraries like Socket.io or SockJS, but this is because they've not seen how clean a long-polling API can actually be.