Show HN: Golongpoll – Go HTTP longpolling library
1–10 of 14 posts
Re: Show HN: Golongpoll – Go HTTP longpolling library
#2When 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 :)
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.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#3Great 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.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#4Great 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.
Yeah. I originally started out using SSE but I ended up settling on longpolling because of wider browser support and the fact that there are issues with SSE even on newer browsers and polyfills. The knee-jerk reaction nowadays is to use websockets for everything, but sometimes simple is better.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#5When 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 :) 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.
I'm pretty sure my blog post with a long polling tutorial was one of those. Glad to see someone improve on the idea and turn it into a lib!
Re: Show HN: Golongpoll – Go HTTP longpolling library
#6> Why does everyone run to websockets even when they only need server-to-client pushing? Probably because it's difficult to get longpolling right.
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.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#7> Why does everyone run to websockets even when they only need server-to-client pushing? Probably because it's difficult to get longpolling right. 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 connect…
There's also EventSource, which I've had some luck with. It's more REST-y, I find.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#8> Why does everyone run to websockets even when they only need server-to-client pushing? Probably because it's difficult to get longpolling right. 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 connect…
WebSockets are superior from a technical perspective, no arguing that. But, long-polling makes for more straightforward APIs, which could be valuable if you're more concerned about developer UX than the number of bytes on the wire.
For example, long-polling can actually be RESTful, so it fits in well with conventional API practices. It's also naturally resilient to network issues since each re-poll heals the stream. Users are very unlikely to lose data due to forgetting about some corner case.
Re: Show HN: Golongpoll – Go HTTP longpolling library
#9> Why does everyone run to websockets even when they only need server-to-client pushing? Probably because it's difficult to get longpolling right. 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 connect…
WebSockets are superior from a technical perspective, no arguing that. But, long-polling makes for more straightforward APIs, which could be valuable if you're more concerned about developer UX than the number of bytes on the wire. For example, long-polling can actually be RESTful, so it fits in well with conventional API practices. It's also naturally resilient to network issues since each re-poll heals the stream.…
Websockets can be RESTful too. I've seen the following:
GET /orders - fetch all orders
GET /orders Upgrade: websocket - streaming view of all new orders
Re: Show HN: Golongpoll – Go HTTP longpolling library
#10Great 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.
Yeah. I originally started out using SSE but I ended up settling on longpolling because of wider browser support and the fact that there are issues with SSE even on newer browsers and polyfills. The knee-jerk reaction nowadays is to use websockets for everything, but sometimes simple is better.
I've been using SSE with Go for personal projects, so just one browser, could you expand on the issues you mentioned? I'm curious if it is indeed as bad as you say.