5 ms·

We provide both long-polling and webhooks but almost everybody chooses to use webhooks. From what I've seen, a reason is that a lot of other tools/ platforms th

We provide both long-polling and webhooks but almost everybody chooses to use webhooks. From what I've seen, a reason is that a lot of other tools/ platforms that you want to integrate with don't support long-polling. They prefer to get notified when something happens instead of keeping a persistent connection.

tonyg 5y ago
A webhook is (ok, squint really hard) a bit like one direction of a TCP connection: state at the sender tracking what the receiver has seen, state at the receiver for rejecting duplicates, logic for retrying and acknowledging receipt. The state management kind of sucks though, and it isn't sufficiently abstracted over, hence the original article. So why can't we use actual TCP connections for long-lived relationships? Because kernels make TCP more fragile than it has to be. There's no particular reason TCP connections couldn't outlive process instances, machine reboots, etc., except for the way TCP is implemented in the kernel.
- tonyg 5y ago
  I should add that the WebSub (previously PubSubHubBub) spec goes some way toward spackling over the gap between raw webhooks and what's needed for long-lived TCP-like relationships. https://www.w3.org/TR/websub/ https://www.w3.org/TR/websub/
- pixl97 5y ago
  > There's no particular reason TCP connections couldn't outlive Are we forgetting about every awful firewall and piece of garbage middleware box out there?
dudeinjapan 5y ago
In TableCheck's API we do the same--both webhooks and events. Our clients (mostly Java/"enterprise") tend to choose polling for events. We also retry webhooks with a backoff timer until we get an HTTP 200 response. When any event has been successfully delivered (either by webhook or by a polling query) it is flagged as "delivered" and doesn't appear in subsequent polling, unless you add an include_delivered=true param.

tonyg 5y ago

A webhook is (ok, squint really hard) a bit like one direction of a TCP connection: state at the sender tracking what the receiver has seen, state at the receiver for rejecting duplicates, logic for retrying and acknowledging receipt. The state management kind of sucks though, and it isn't sufficiently abstracted over, hence the original article. So why can't we use actual TCP connections for long-lived relationships? Because kernels make TCP more fragile than it has to be. There's no particular reason TCP connections couldn't outlive process instances, machine reboots, etc., except for the way TCP is implemented in the kernel.

tonyg 5y ago
I should add that the WebSub (previously PubSubHubBub) spec goes some way toward spackling over the gap between raw webhooks and what's needed for long-lived TCP-like relationships. https://www.w3.org/TR/websub/ https://www.w3.org/TR/websub/
pixl97 5y ago
> There's no particular reason TCP connections couldn't outlive Are we forgetting about every awful firewall and piece of garbage middleware box out there?

dudeinjapan 5y ago

In TableCheck's API we do the same--both webhooks and events. Our clients (mostly Java/"enterprise") tend to choose polling for events. We also retry webhooks with a backoff timer until we get an HTTP 200 response. When any event has been successfully delivered (either by webhook or by a polling query) it is flagged as "delivered" and doesn't appear in subsequent polling, unless you add an include_delivered=true param.