If it feels a lot like reinventing the wheel, well, it’s because it is.
Time that I could better spend building products for our customers. It depends on your current architecture, but in short, that’s a lot of new tools, a lot of new code, and especially a lot of time. However, to handle a single webhook safely, you would need (as per Clubhouse) 4 new services (SQS, S3, a Publisher(s) and a Consumer(s)). Clubhouse.io engineering team wrote a great article on this topic. You aren’t supposed to take action directly on a webhook! That’s right, the “proper way” of dealing with webhooks is to postpone any meaningful processing through the use of queues and to handle errors & retries on your own. “Queue first, take action later”, they said If these are mission-critical webhooks, are you confident you can find and take action on every single webhook you missed? Maybe, but most likely, you’ll spend the day on it. You probably have server logs or even better, something like Sentry to catch unexpected exceptions in your code. Even with the best integration tests, you are probably not prepared for unexpected payload changes (perhaps a stealth API version upgrade) or a platform downtime. Every once in a while, you will introduce errors in your webhook handling methods. It’s April 2020, we are stuck inside self quarantining, productivity has been high, and it just strikes me as the perfect time to publish my first post. My key takeaway is that it sucks to deal with multiple APIs incoming webhooks such as Shopify, Stripe & Intercom, and I hate not having an alternative. I’ve been working in e-commerce for the last three years dealing with millions of fairly mission-critical webhook events.
0 kommentar(er)
