Webhooks 真糟糕，但这里有一些替代方案
Webhooks 是 Web 基础设施的基础部分。在 2007 年的一篇博文中被创造出来，webhooks 被建议作为一种使用所有 Web 开发人员都熟悉的协议（HTTP）来消费异步 feed 的简单方法。现在是 2024 年，webhooks 或多或少保持不变，但它们已成为事实上的方法，不仅用于单向通知，还用于集成云系统。
在 Web 时代，管道的等价物是什么？
— Tim O’Reilly
今天，webhooks 无处不在。对于 SaaS 和 API 公司来说，webhooks 是基本条件 —— 为他们提供与其他云软件集成的机会的最低开发成本。根据 SVIX 的数据，在排名前 100 的 API 公司中，83% 提供 webhooks。对于 SaaS 企业来说，提供集成的第一步是通过 webhooks。因此，如果您正在构建云软件，您应该提供 webhooks 并就此为止，对吗？
不完全是。
Webhooks 没有与时俱进
Webhooks 最初在 2007 年被提出作为一种用于跨互联网消费异步 feed 的标准化解决方案，此后已发展为服务于更广泛的目的：允许云系统之间集成的权宜之计。
随着云软件和 SaaS 的兴起，您的数据的效用取决于它可以存在于多少其他系统中。您的用户数据在您的分析工具中很棒，但在您的电子邮件工具、重定向工具等中会更好。每个 SaaS 都必须提供与其他 SaaS 的集成，而最简单的方法是通过 webhooks。
但让我们花点时间问问自己：在 SaaS 的背景下，我们用 webhooks 解决什么问题？
大多数对消费 SaaS webhooks 感兴趣的开发人员都在寻求自定义 —— 自定义工作流程、自定义数据转换、自定义管道到自定义系统。考虑到这些标准，webhooks 仍然是最佳解决方案吗？
Webhooks 的隐藏成本
有兴趣消费 webhooks 以启动自定义工作流程或执行自定义处理的开发人员必须进行大量的开发工作。他们必须
- 创建一个服务器
- 编写一个路由处理程序
- 解析有效负载
- 构建自定义处理
- 将服务器部署和托管在始终可用的地方
- 维护代码
- 测试和排除代码故障
在您意识到 50% 的 webhook 由外部方管理之前，测试 webhooks 可能看起来很简单。而且每个 webhook 提供商都有自己的规则和逻辑。如果他们的 webhook 表现出未记录的非常规行为怎么办？如果他们的终端出现错误怎么办？围绕开发、测试和排除 webhooks 故障存在许多陷阱。
总而言之，上面列出的列表是消费 webhook 的最简单方法。事实上，由于 webhooks 的短暂性（如果您没有收到 webhook，则不可能再次发送 webhook），许多工程团队普遍认为，使用队列来处理 webhooks 是最佳实践，然后自行处理错误和重试。但是，使用这种更强大的设置，您将需要 4 个新服务（SQS、S3、一个发布者和一个消费者），仅仅是为了安全地处理单个 webhook。这需要大量的新基础设施、架构、时间和精力。
成功消费 webhook 的责任在于开发人员，他们有很多搞砸的机会。
对于有兴趣在您的产品中创建自定义工作流程的客户来说，消费 webhook 需要大量的开发开销。老实说，没有开发人员会为了处理 webhook 而设置队列和多个无服务器基础设施。
有哪些替代方案？
用户想要可定制性
用户只是想根据自己的需求自定义工作流程。从这个角度来看，有一些 webhooks 的替代方案可以提供更好的体验
工作流程构建器
我们都知道 Zapier。他们做得很好，几乎将所有云软件变成了您可以连接以实现您可以想象的任何工作流程的块。他们的可视化工作流程构建器简化了处理来自各种 SaaS 生成的复杂数据集。
但您的界面不需要像 Zapier 的那样复杂。在某些情况下，一个简单的 HTML 表单可以为您的用户提供足够的自定义。例如，SMS 营销工具可以提供一个简单的 UI，允许最终用户构建自定义短信，而不是在每次有新的电子邮件订阅者时发送 webhook。或者，支付处理器可以为最终用户提供一个界面来发送自定义确认电子邮件，而不是在每次有新的“订阅升级”事件时发送 webhook。
您可能会认为这些工作流程构建器的功能可能有点受限（除非您的工程师有无限的时间和咖啡），因此还有下一个替代方案。
浏览器内 IDE
为了获得最大的灵活性和自定义性，同时最大限度地减少开发工作，您可以在您的产品中提供一个浏览器内代码编辑器，您的用户可以在其中编辑和部署具有 HTTP 访问权限的函数，以进行处理和触发其他工作流程。
您的开发人员不再需要创建和管理生产级基础设施。他们也不需要切换上下文，因为他们可以直接在浏览器中编辑代码。最后，既然更多的逻辑在您的基础设施上，您现在可以提供更好的测试、日志记录和可观察性。
还有其他好处。您的浏览器内 IDE 可以开箱即用地提供辅助库，因此您的开发人员无需自行查找或安装任何内容。您还可以通过指南、工具提示、文档来配合您的浏览器内开发体验，以引导您的开发人员朝着正确的方向前进。由于您可以更好地控制端到端的 webhook 消费体验，因此有很多机会消除繁琐的步骤或样板代码，从而最大限度地提高成功的机会。
🚨️ 想要构建云 IDE，但担心部署和执行不受信任代码的安全性？查看 Subhosting。
想象一下，不是针对新订阅事件的 Wordpress webhook，而是一个浏览器内编辑器，您可以在其中抓取订阅者信息，填充并发送欢迎电子邮件？或者，不是针对新客户的 Stripe webhook，而是浏览器内 IDE 允许您编写一个处理程序，该处理程序在您的 HubSpot 中填充新记录？
我们可以做得比 webhooks 更好
由于 webhooks 的简单性、灵活性以及开发人员的熟悉程度，webhooks 是互联网基础设施的关键组成部分。然而，自 2007 年以来，互联网、Web 开发人员和最终用户消费者都发生了巨大的变化，他们的需求也发生了变化。消费者不再是处理异步 feed，而是想要自定义工作流程，以便他们可以更轻松、更快速地完成工作，从而更好地为他们的消费者服务，但不幸的是，webhooks 不再能满足需求。现在是我们提供更好的围绕自定义工作流程的开发者体验的时候了。
不要错过任何更新 — 在 Twitter 上关注我们。