5 ms·

> One idea for Stripe and other API platforms: support long-polling! It’s great that we’ve went full circle. But make no mistake that this only means one thing

by atian 5y ago

> One idea for Stripe and other API platforms: support long-polling! It’s great that we’ve went full circle. But make no mistake that this only means one thing: that servers are cheaper than ever. We can now afford to entertain previously extravagant ideas.

simonw 5y ago
Long polling is a lot easier to support now than it was a few years ago, thanks to the wide availability of async server frameworks - Node.js, Python ASGI etc - which make supporting thousands of simultaneous long-polling connections with a single server much less expensive.
- deleted 5y ago
  [deleted]
maerF0x0 5y ago
also the OP seems to ignore all the issues with webhooks that longpolls suffers or is worse at. eg: you'll lose all those tcp connections if your service is down -- one of the main complaints about webhooks...
- coldacid 5y ago
  Which, if the parts discussed before long-polling was mentioned were implemented, wouldn't be an issue since you'd be starting from the first event following your last-recieved cursor anyway.
deleted 5y ago
[deleted]
Anunayj 5y ago
I've have had a couple issues implementing Long Polling in the past. At times I've had the firewall or reverse proxy drop client connections if it detects no data transfer. Which meant I had to timeout all the requests every 30 secons or so. Make a new request before the other one ends, and it all becomes messy. At this point, its honestly just easier to just have a websocket + events endpoint with a cusor both.
- nitwit005 5y ago
  I wouldn't recommend long polling for this reason. There are also some security products that have trouble with what appears to be a long file download. Websockets or server sent events at least signal to intermediaries that a longer term connection will be open.
historyloop 5y ago
> It’s great that we’ve went full circle. But make no mistake that this only means one thing: that servers are cheaper than ever. We can now afford to entertain previously extravagant ideas. We've not come full circle. This is just one blog saying "how about long-polling". While also ignoring that since then we've gained web sockets, HTTP/2 and HTTP/3, each of which make long-polling pointless in three different ways.
- MrStonedOne 5y ago
  >While also ignoring that since then we've gained web sockets, HTTP/2 and HTTP/3, each of which make long-polling pointless in three different ways. None of those have strong support across language frameworks for using them as a client from a server context. Especially http/3.
  - historyloop 5y ago
    What language exactly you use that can't do web sockets, which is a thin layer over plain TCP sockets?
    - MrStonedOne 5y ago
      dream maker (which can do http, but not websockets or tcp sockets), php: https://stackoverflow.com/questions/7160899/websocket-client-in-php https://stackoverflow.com/questions/7160899/websocket-client... , tcl.
gwbas1c 5y ago
But Long-polling doesn't scale in certain situations where you can have infinite webhooks. I'm sure many people reading this have many idle GitHub repos set up with webhooks into some kind of build server. The repo might see no more than one commit a week. It makes absolutely no sense for GitHub to long-poll (or websocket) all of these build servers. (Now what would make sense is for /events to support a way to flip over to a webhook when it's idle. IE, long-poll for a minute, then the next request sends a URL for a 1-time webhook called on the next event.)

by atian 5y ago

simonw 5y ago

Long polling is a lot easier to support now than it was a few years ago, thanks to the wide availability of async server frameworks - Node.js, Python ASGI etc - which make supporting thousands of simultaneous long-polling connections with a single server much less expensive.

deleted 5y ago
[deleted]

maerF0x0 5y ago

also the OP seems to ignore all the issues with webhooks that longpolls suffers or is worse at. eg: you'll lose all those tcp connections if your service is down -- one of the main complaints about webhooks...

coldacid 5y ago
Which, if the parts discussed before long-polling was mentioned were implemented, wouldn't be an issue since you'd be starting from the first event following your last-recieved cursor anyway.

deleted 5y ago

[deleted]

Anunayj 5y ago

I've have had a couple issues implementing Long Polling in the past. At times I've had the firewall or reverse proxy drop client connections if it detects no data transfer. Which meant I had to timeout all the requests every 30 secons or so. Make a new request before the other one ends, and it all becomes messy. At this point, its honestly just easier to just have a websocket + events endpoint with a cusor both.

nitwit005 5y ago
I wouldn't recommend long polling for this reason. There are also some security products that have trouble with what appears to be a long file download. Websockets or server sent events at least signal to intermediaries that a longer term connection will be open.

historyloop 5y ago

> It’s great that we’ve went full circle. But make no mistake that this only means one thing: that servers are cheaper than ever. We can now afford to entertain previously extravagant ideas. We've not come full circle. This is just one blog saying "how about long-polling". While also ignoring that since then we've gained web sockets, HTTP/2 and HTTP/3, each of which make long-polling pointless in three different ways.

MrStonedOne 5y ago
>While also ignoring that since then we've gained web sockets, HTTP/2 and HTTP/3, each of which make long-polling pointless in three different ways. None of those have strong support across language frameworks for using them as a client from a server context. Especially http/3.
- historyloop 5y ago
  What language exactly you use that can't do web sockets, which is a thin layer over plain TCP sockets?
  - MrStonedOne 5y ago
    dream maker (which can do http, but not websockets or tcp sockets), php: https://stackoverflow.com/questions/7160899/websocket-client-in-php https://stackoverflow.com/questions/7160899/websocket-client... , tcl.

gwbas1c 5y ago

But Long-polling doesn't scale in certain situations where you can have infinite webhooks. I'm sure many people reading this have many idle GitHub repos set up with webhooks into some kind of build server. The repo might see no more than one commit a week. It makes absolutely no sense for GitHub to long-poll (or websocket) all of these build servers. (Now what would make sense is for /events to support a way to flip over to a webhook when it's idle. IE, long-poll for a minute, then the next request sends a URL for a 1-time webhook called on the next event.)