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 启动自定义工作流程或执行自定义处理感兴趣的开发人员必须进行非同寻常的开发工作。他们必须
- 创建一个服务器
- 编写路由处理程序
- 解析有效负载
- 构建自定义处理
- 部署并将服务器托管在始终可用的位置
- 维护代码
- 测试和调试代码
测试 webhooks 似乎很简单，直到您意识到 50% 的 webhook 由外部方管理。而且每个 webhook 提供商都有自己的规则和逻辑。如果他们的 webhook 表现出不寻常的行为，而这些行为没有记录怎么办？如果他们的系统出现错误怎么办？在开发、测试和调试 webhooks 周围有很多陷阱。
总而言之，上面的列表是使用 webhook 的最简单方法。事实上，由于 webhooks 的短暂性（如果您没有收到 webhook，就无法让 webhook 重新发送），许多工程团队认为使用队列处理 webhooks 是最佳实践，然后自行处理错误和重试。但是，使用这种更强大的设置，您需要 4 个新服务（SQS、S3、发布者和消费者），只是为了安全地处理单个 webhook。这需要很多新的基础设施、架构、时间和精力。
成功使用 webhook 的责任在于开发人员，他们有很多机会搞砸。
对于有兴趣在您的产品中创建自定义工作流程的客户来说，使用 webhook 需要大量的开发开销。说实话，没有开发人员会为了处理 webhook 而设置队列和多个无服务器基础设施。
有什么替代方案？
用户想要可定制性
用户只是想根据自己的需要定制工作流程。从这个角度来看，webhooks 有几种替代方案可以提供更好的体验
工作流程构建器
我们都知道 Zapier。他们做得很好，将几乎所有云软件都变成了可以连接起来实现您能想到的任何工作流程的模块。他们的可视化工作流程构建器简化了处理来自各种 SaaS 的复杂数据集。
但您的界面不需要像 Zapier 的界面那样复杂。在某些情况下，一个简单的 HTML 表单可以为您的用户提供足够的自定义选项。与每当有新电子邮件订阅者时就发送 webhook 不同，短信营销工具可以提供一个简单的 UI，允许最终用户构建定制的短信。或者，与每当有新的“订阅升级”事件时就发送 webhook 不同，支付处理器可以提供一个界面，让最终用户发送自定义确认电子邮件。
您可能认为这些工作流程构建器在功能上可能有点受限（除非您的工程师有无限的时间和咖啡），因此有下一个替代方案。
浏览器内 IDE
为了获得最大的灵活性和可定制性，同时最大限度地减少开发工作量，您可以在您的产品中提供一个浏览器内的代码编辑器，让您的用户可以编辑和部署一个具有 HTTP 访问权限的函数，用于处理和触发其他工作流程。
您的开发人员不再需要创建和管理生产级基础设施。他们也不需要切换上下文，因为他们可以直接在浏览器中编辑代码。最后，您可以提供更好的测试、日志记录和可观察性，因为更多的逻辑都在您的基础设施上。
还有其他好处。您的浏览器内 IDE 可以开箱即用地提供辅助库，因此您的开发人员无需自行查找或安装任何库。您还可以将您的浏览器内开发体验与指南、工具提示、文档相结合，以引导您的开发人员走上正轨。由于您可以更好地控制端到端 webhook 使用体验，因此有很多机会消除繁琐的步骤或样板代码，以最大限度地提高成功的机会。
🚨️ 想构建云 IDE，但担心部署和执行不可信代码的安全性吗？查看 Subhosting.
想象一下，与 WordPress 为新订阅事件提供的 webhook 不同，有一个浏览器内编辑器，您可以在其中获取订阅者信息，填充并发送欢迎电子邮件？或者，与 Stripe 为新客户提供的 webhook 不同，浏览器内 IDE 允许您编写一个处理程序，该处理程序将在您的 HubSpot 中填充一条新记录？
我们可以做得比 webhooks 更好
Webhooks 是互联网基础设施的重要组成部分，因为它简单、灵活，并且开发人员熟悉它。但是，互联网、Web 开发人员和最终用户消费者自 2007 年以来已经发生了很大变化，他们的需求也随之改变。消费者不再需要处理异步 feed，而是想要自定义工作流程，以便他们能够更轻松、更快速地完成工作，从而更好地为他们的消费者提供服务，不幸的是，webhooks 已经不能满足他们的需求了。现在是时候为定制工作流程提供更好的开发人员体验了。
不要错过任何更新 — 关注我们的 Twitter。