部署自定义操作的三种方式

前言

部署自定义操作最快的方式是什么？哪种设置最灵活，能让您完全定制自己的工作流？您选择用于捕获和处理自定义操作的环境是决定在后续工作流步骤中可以对数据执行哪些操作的重要因素。基本选择包括：

1. 无代码部署，使用 Zapier、Integromat 或 Microsoft Power Automate 等自动化平台
2. 低代码解决方案，如 AWS Lambda 或 Azure Functions，您可以在完全托管的环境中将简单的脚本作为“作业”运行；
3. 您运行和维护的服务器

下图展示了自定义操作的架构：

无代码：部署到 Zapier

Zapier 的“点击即创建”界面是基础自动化场景的不错选择，您的目标是将资产、评论或状态事件从 Frame.io 发送到常用的应用程序或生产力工具。

优点

• 使用简单。通过点击即可创建自动化。
• 任务历史记录是 Zapier 的运行时日志工具，能够总结每次自动化运行中每个工作流步骤的数据输入/输出。
• 付费购买高级帐户可解锁路径，这是一个用于为自动化构建和添加分支逻辑的工具。

缺点：

• Zapier 对 Webhook 的支持有限，它不支持在自定义操作运行时发送详细消息或与 Frame.io 用户进行任何交互。该限制在 Zapier 支持文档中有说明：

我们 [Zapier] 在收集 Webhook 时始终返回一条成功消息，并附带调试信息的负载——无论 Webhook 背后是否有 Zap，也无论该 Zap 是否处于暂停状态…您无法自定义对发送到 Catch Hook URL 的请求的响应，因为响应是在 Zap 触发并在 Webhook 请求上运行之前就已经发送了。

• 在验证自定义操作是否正常运行时，Zapier 的用户界面可能会比较繁琐。例如，在测试时需要检查和刷新测试数据；如果测试数据与您的实时数据不匹配，即使您的 Zap 设计实际上是正确的，Zapier 也可能会抛出“假阴性”并显示错误。如果当某个任务期望获取关键数据（如文件 URL）时该数据不可用，您的 Zap 可能会出错或无法按预期运行。

低代码：部署到 AWS

自定义操作可以发送到 AWS 中的 API Gateway，并与 Amazon 庞大且著名的云服务套件进行集成。最简单的模式是将自定义操作中包含的 Frame.io 事件代理到 AWS Lambda——一种用于运行无服务器函数的计算服务。以下是一个文件存档服务的设计示例：

优点：

• AWS 免费套餐每月可为您提供 320 万秒的计算时间，之后才会收取服务费用。
• API Gateway 和 Lambda 支持出色的测试和监控工具，如 CloudWatch 和 X-Ray。
• 服务可以扩展以支持超大文件（500 GB 以上）

缺点：

• 将多个服务（Webhook -> API Gateway -> Lambda 1 -> Lambda 2）拼接在一起，或学习如何使用 AWS Fargate 等较新的服务，可能会比较耗时。
• AWS 文档通常已过时或缺少关键细节。例如，在配置 API Gateway 时，很难判断负载是否会进行 Base64 编码。
• 配置通常有点复杂。

请参阅相关指南，了解如何将自定义操作部署到 AWS 的完整流程。注意：您可以将自定义操作部署到任何云计算服务，而不仅仅是 AWS（Azure、Google Cloud Platform、Digital Ocean 等）

运行服务器并托管您自己的代码

云服务非常便捷，但对于那些您希望完全掌控数据的工作流，您可能会选择编写和部署自己的服务器。

在 DevRel 团队中，我们喜欢用 Python 编写 FastAPI 服务器。它们易于创建，并且非常适合自定义操作的请求-响应模式。

优点：

• 控制数据的端到端流动。完全没有意外情况。
• 可以将数据同步到 NAS 或文件系统，而无需额外暴露在云端。

缺点：

• 需要管理服务器、构建自己的安全功能、处理网络发现、负载等。

克隆我们的示例代码来部署一个用于处理自定义操作的 FastAPI 服务器。

我们来讨论最适合您需求的设计方案

将您的需求发布到我们的社区，我们很乐意帮助您找出最适合您工作流的设计方案。