

Ask HN: How to clone Stripe webhooks - logvol

Stripe has a great API. Pretty much everyone I&#x27;ve talked to about it agrees, and it&#x27;s often cited as a solid example of a best practice.<p>One of the best parts is their webhooks. The question is: how can I clone them?<p>I read in a blog post somewhere that the webhooks are based in large part upon a MongoDB collection that acts as a message queue. Sounds like a solid piece of advice, and I understand how Mongo&#x27;s non-relational data storage makes for a pretty slick way of persisting events&#x2F;messages. Besides that... any other hints? I&#x27;m look at you, Stripe devs.<p>Alternatively, are there SaaS services or open source libraries that help with this problem or am I stuck re-inventing the wheel?
======
patio11
Version 1.0 can be out in an hour and requires one page to register webhooks,
one place to store outgoing event data (which can be in anything -- a SQL
database with a column representing a JSON bag-of-serialized-attributes will
work fine), and a cron job. The minimum implementation is not difficult
engineering.

A lot about what Stripe does right is in the ancillary bits about consuming
their webhooks:

1) Spend a lot of time thinking about what your retry policy is. Some service
providers (including ones which I like) will do one callback and then not
retry. This is often suboptimal for consumers. I personally like "retrying
with expotential decay", which is a nice balance between "You get your webhook
really, really quickly if a gremlin just happened to eat the first one" and
"If your servers are experiencing hard downtime, we won't add to the problem
by pinging the heck out of you."

2) There is no SaaS or open source option for "Have great documentation, at
once both comprehensive and easy to consume for the goal-oriented developer."

3) There are a lot of failure modes for webhook systems, some of which you'll
only discover when operating them. Transient network problems between your
application and the consumer's. "Failure to agree on reality" between
different moving parts of your application. Adding webhooks to the outgoing
queue in a non-idempotent fashion, which seems to be one of the great Let Me
Tell You About This One Timee stories in systems engineering. Timing issues
with consumers receiving webhooks in an order other than that which they would
logically expect, which might not be your problem but good luck convincing a
customer of that.

You'll want to have instrumentation and monitoring up that wazoo, so you can
resolve these little usage niggles. This boring, iterative execution on the
base feature is approximately 99% of why really well-executed APIs (like
Stripe or Twilio or whomever) are really fun to work with and, well, why there
exist some APIs which are less fun to work with.

~~~
logvol
Hey Patrick, stoked to hear your response! Solid advice all around, I
definitely agree! Unfortunately, I was looking for something more than just
"do a lot of work and do it well"... but I might just be wishing for something
too good to be true!

On a related note, one of my favourite features of the Stripe webhooks is the
UI for showing logs/events/etc. Makes developing SO MUCH easier when it's not
just some magic black box.

------
jasonfill
Ping me at jason <at> webhooks.io and we can chat more about what you are
looking for, I might have something that can help you with this.

