Webhooks 之谷

我已经第三次在三个不同的公司、三个不同的提供商构建了相同的系统三次。它从来没有名字，也从未出现在路线图上，但它总是以同样的方式进行：有关您自己客户的真相存在于其他人的数据库中。用户生活在身份提供商中，Stripe 中的订阅，发送电子邮件的任何内容的退回，而您的产品在本地需要这一事实。因此，您订阅了 webhooks 并保留了一份副本。第一次，我以为我正在构建一个端点：一个解析 JSON 并更新一行的路由，一个下午的工作。下午变成了一周。首先是签名验证，因为改变数据库的开放端点是一个漏洞。然后是重复数据删除表，因为交付到达两次，文档高兴地称之为“至少一次”。然后处理程序得到一个缓冲区，因为membership.created有时会出现在它指向的user.created之前。然后是引导导入程序，因为 webhooks 只告诉您订阅后会发生什么，并且它会与实时事件竞争，因此它发展了一个锁定方案。最后是协调 cron：这项工作会在凌晨 3 点抓取提供商的 API 列表，将它们与我们的表进行比较，并悄悄地修复不一致的内容。我想诚实地了解那个 cron 是什么。这是一份书面的认罪书。它说：我不信任我构建的副本，我无法知道它什么时候出错，所以我每天晚上都会从头开始重新推导它，永远。信任消失是有原因的。漂移永远不会自行显现；我们是通过支持票找到的。一位客户在几个月前取消了订单，而我们的数据库仍然显示处于活动状态；一些 customer.subscription.deleted 在 Stripe 和我们之间消失了，任何地方都没有注意到：不是他们的仪表板，它显示了重试并最终丢弃的交付，也不是我们的日志，它无法记录从未到达的请求。这只是代码。每个提供商还自带自己的仪表板。三个提供程序、三个 Webhook 配置页面，每个页面都有自己的想法：如何注册端点、存在哪些事件、如何分隔测试和实时环境以及签名秘密所在的位置。当出现问题时，调试就是一次游览：他们的交付日志在一个选项卡中，我们的日志在另一个选项卡中，第三个选项卡用于我当前怀疑的仪表板。它们看起来都不一样，都必须进行检查。当我第三次构建这个系统时，我已经不再假装了。我预先对整个堆栈进行了预算（签名、重复数据删除、缓冲、引导程序、cron），在编写第三个重复数据删除表的过程中，我终于问了我应该第一次问的问题。我到底要在这里重建什么？通知不是我正在重建有序日志的数据。这些集成中的每一个都是试图将通知流转回其来源的有序、完整、当前的历史记录。这是荒谬的部分：历史存在。它必须如此，因为它位于提供者内部；这就是他们呈现仪表板、事件页面和 Webhook 重放工具的方式。提供者获取他们有序的日志，将其粉碎成单独的 HTTP POST，通过既不保证顺序也不保证交付的通道在我的端点处触发它们，然后我在我这边重新组装日志。其他每个独立的消费者也是如此，每个人都有自己的错误。这是一个拼图游戏，制造商有原始图片，将其剪碎，一次邮寄给我一块，在邮寄过程中丢失了一些，邮寄了两次，并且在盒子上没有打印任何内容。当我组装的拼图与原始拼图不匹配时，他们的支持团队会问我缺少哪些拼图。我不知道，这就是整个问题：没有任何东西表明存在差距。这些都不是任何提供商的错误。他们的 webhook 的工作方式与记录的完全一样。问题在于 webhook 是什么：一个通知，“发生了一些事情，这里有一个关于它的帖子。”通知是触发副作用的好方法，也是传输数据集的糟糕方法，在我们开始将它们用于第二件事的过程中，我们没有注意到我们已经换了工作。这如何成为常态？没有人决定这个。 “webhook”这个术语是由 Jeff Lindsay 在 2007 年创造的，早期的用途确实很合适：GitHub 的 post-receive hooks 启动 CI 构建，或者支付事件 ping 您的服务器，以便它可以通过电子邮件发送收据。我们的工作是在事情发生时做一件事，为此，POST 是完美的：当忘记可以时，即发即忘也可以。 Webhook 之所以能够传播，是因为它们是提供商可以运送的最便宜的东西（一个 HTTP POST），也是消费者可以接收的最便宜的东西（您已经有一个 Web 服务器，所以您只需添加一条路由）。到 2010 年代初期，“我们有 webhooks”是每个 API 登陆页面上的一个复选框，并且该复选框从未区分两个截然不同的作业：触发副作用：发送收据、启动构建、ping 通道