Comment by e12e | Hacker News Reader

Comment by e12e | Hacker News Reader

Thanks for summing up, concisely, why webhooks really aren't magic at all, in the fourth paragraph:

"All [webhooks] are is a promise by an application or API: “when this thing happens, I’ll send this HTTP request with this data.”"

It's nice to see that all the hype really just boils down to generalized pingbacks[1]. Now, having a standard is great -- I'm not entirely sure we have a standard yet, though. It's more like a fancy name for pingbacks that aren't just for blog posts.

I'm also not entirely sure if I'd prefer webhooks for eg. processing emails. Emails are naturally "push" -- they get pushed via SMTP. I know that people are scared of email/SMTP -- but it seems quite a lot easier to make sure you don't loose any "events" with SMTP than with HTTP(S).

What if your site is down for a few minutes, just as some service out there tries to "ping" you with a webhook? Email handles that.

I think what most people seem to mix up is that handling "real" email may be hard -- but looking for a well formed subject that exactly matches some regex, then parsing that, isn't that hard. Everything else you can either bounce (a little dangerous) or just drop (not quite as dangerous).

Mailing-lists work. What you need isn't much more complicated. Maybe allow for a mime-part with a json or xml, or some other well-formed body. Use gpg or smime to encrypt data, if you need something more than a short hash/token.

[1] http://en.wikipedia.org/wiki/Pingback

Part of the problem has traditionally been that email servers haven't been as easy to "hack" as web servers have. That was a failing on the part of the developers of those servers.

Thankfully now you have things like Qpsmtpd, James, Lamson and Haraka which can do those things for you. But not many people install those servers. I'd love to see that change (for obvious reasons).

Partly. But you've been able to do the equivalent of:

    echo "|magic-program" > .forward

For a long, long time. Granted, it's a little unclear what happens if you manage to overload your server doing that, but in general MTAs are pretty good at taking care of your mail, either queueing and delivering, or giving up somewhat gracefully.

The trick is to make sure that the "magic-program" is simple and robust -- and that isn't quite as hard as most people think, if you don't require it to parse arbitrary emails -- just accept and parse clearly valid ones, and reject everything else.

Now, if you require to handle enough incoming requests that forking a process per mail is a problem ... you probably need to fix your architecture.

The fragility of parsing emails is a big problem though. But I agree that for the equivalent of webhooks it is the perfect platform, and simple scripts work. Except at scale.

The interesting thing about SMTP is that a mail transfer agent is typically built using queues for both outbound and inbound transmission. Those queues help ensure durability of a message. You could implement webhooks with a transmission queue, retrying for a bit, maybe giving up depending on the nature of webhook. The awesome part about SMTP is that there is so much existing infrastructure in place, although some agents aren't as reliable as others at delivery.

Web crowd continues to struggle with the concept of interrupts, what else is new?

Reply on news.ycombinator.com