Show HN: Golongpoll – Go HTTP longpolling library • Hacker News Board

Re: Show HN: Golongpoll – Go HTTP longpolling library

#11

Post by jkarneges » Thu, Nov 12, 2015, 9:17 AM UTC

RyanZAG wrote: post #9

jkarneges wrote: post #8

Earlier quoted context omitted.

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 The problem with this type of RESTful integration though is the connection limit imposed by browsers. Of course, long poll has the identical problem. You can't long poll more than a couple endpoints.

True, you can use URI paths with WebSockets which at least makes the streams resource-oriented. CBIX does it: https://www.cbix.ca/api-websocket

I think calling this RESTful is a bit of a stretch though, at least in any conventional sense of what that means to people.

Re: Show HN: Golongpoll – Go HTTP longpolling library

#12

Post by jondubois » Thu, Nov 12, 2015, 9:22 AM UTC

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.

TCP and WebSockets are stateful, HTTP is stateless. So long polling is essentially:

Stateful -> Stateless -> Sateful

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...

Re: Show HN: Golongpoll – Go HTTP longpolling library

#13

Post by regecks » Thu, Nov 12, 2015, 9:45 AM UTC

jondubois wrote: post #12

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. TCP and WebSockets are stateful, HTTP is stateless. So long polling is essentially: Stateful -> Stateless -> Sateful 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 starte…

Maybe in "fat" language runtimes this is a problem (Ruby, Java, Python etc).

In Go, requests are a single goroutine, dirt cheap (no problem with a single CPU). To me, this type of work is where Go excels.

I used SSE (not quite long polling but I think it has the same implications as far as this discussion goes) back in Go 1.3 days (so GOMAXPROCS=1) to write metrics to 100As far as complexity .. well, sure, if you fuck up the design or use the wrong tool for the job you'll have problems.

Re: Show HN: Golongpoll – Go HTTP longpolling library

#14

Post by regecks » Thu, Nov 12, 2015, 9:50 AM UTC

bittersweet wrote: post #10

jcuga wrote: post #4

Earlier quoted context omitted.

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.

Doesn't work in IE, last I checked.