3 ms·

Webhooks are great, until you don't get one... Then they suddenly become a nightmare.

by richardlblair 13y ago

paddyforan 13y ago
That's why logs from the webhook provider are important. :)
- jessaustin 13y ago
  Yuck. Who wants to deal with that? b^)
- philsnow 13y ago
  That sounds even worse than: > "I watch people poll APIs or create convoluted connections, and I cry a little on the inside." If the action being sent by the webhook is really important, there seems to be no way around doing it somewhat like this: Write a polling (or hanging-get) system, but use webhooks as an unreliable but lower-latency push mechanism. In this setup, webhooks give you low-latency updates (when they work), and polling ensures completeness.
  - drivebyacct2 13y ago
    Sounds like a reinvention of Pubsubhubbub anyway.
  - roarroar 13y ago
    Depending on your requirements the remote end can be responsible for ensuring that you receive and acknowledge the wake up. Once you hit your own timeout you might do any number of things, not necessarily repoll the other end.
philsnow 13y ago
I came across http://blog.iron.io/2013/01/queue-webhook-events-with-ironmq.html http://blog.iron.io/2013/01/queue-webhook-events-with-ironmq... This is pretty sweet, but it seems like it might be more useful for the baked-in reliability to be on the remote end. That is, the side sending the POSTs should notice that it didn't get a 200 reply and retry some number of times with backoff. Also, the POSTs need to be idempotent (include a sequence number or nonce or something) so that if the "200 OK" gets lost and the sending side retries, you can discard the duplicates on the receiving side. That's of course a lot harder since you have to convince everybody whose service you want to use that this is worth the time/effort :)
- richardlblair 13y ago
  Sure, that works... but what happens when the service sending the webhook has an issue on their end and they can't send webhooks they should have? Then you are still out a webhook, and your life still sucks...

Webhooks are great, until you don't get one... Then they suddenly become a nightmare.

paddyforan 13y ago

That's why logs from the webhook provider are important. :)

jessaustin 13y ago
Yuck. Who wants to deal with that? b^)
philsnow 13y ago
That sounds even worse than: > "I watch people poll APIs or create convoluted connections, and I cry a little on the inside." If the action being sent by the webhook is really important, there seems to be no way around doing it somewhat like this: Write a polling (or hanging-get) system, but use webhooks as an unreliable but lower-latency push mechanism. In this setup, webhooks give you low-latency updates (when they work), and polling ensures completeness.
- drivebyacct2 13y ago
  Sounds like a reinvention of Pubsubhubbub anyway.
- roarroar 13y ago
  Depending on your requirements the remote end can be responsible for ensuring that you receive and acknowledge the wake up. Once you hit your own timeout you might do any number of things, not necessarily repoll the other end.

philsnow 13y ago

I came across http://blog.iron.io/2013/01/queue-webhook-events-with-ironmq.html http://blog.iron.io/2013/01/queue-webhook-events-with-ironmq... This is pretty sweet, but it seems like it might be more useful for the baked-in reliability to be on the remote end. That is, the side sending the POSTs should notice that it didn't get a 200 reply and retry some number of times with backoff. Also, the POSTs need to be idempotent (include a sequence number or nonce or something) so that if the "200 OK" gets lost and the sending side retries, you can discard the duplicates on the receiving side. That's of course a lot harder since you have to convince everybody whose service you want to use that this is worth the time/effort :)

richardlblair 13y ago
Sure, that works... but what happens when the service sending the webhook has an issue on their end and they can't send webhooks they should have? Then you are still out a webhook, and your life still sucks...