Lambda集成与Lambda代理:优点和缺点

Question

您认为在AWS API Gateway中使用和不使用代理功能的Lambda集成的优点和缺点是什么(更具体地说,在使用无服务器框架时)？这是我现在的想法:

Lambda与代理集成

• Pro:人们可以快速进行原型设计和编码,而无需担心所有必需的配置细节(并重新发明一些轮子,如通用模板映射等).
• Pro:返回任何状态代码和自定义标题非常容易,同时还有一种通用的方法来读取请求的正文,标题和参数.
• Con:一切都在代码中完成,因此自动生成文档有点困难.依赖关系(标题,模型,返回的状态代码)在代码中"隐藏".

没有代理的Lambda集成

• Con:需要更多的工作来设置它,并且这种配置可能在不同的资源中重复.
• Pro:它允许人们分离lambda接收和返回的内容,以及如何将其映射到不同的HTTP状态代码,标头和有效负载.
• Pro:非常有用,因为它预先规定了它返回的内容,以及它在标题和有效负载方面的要求.
• Pro:从长远来看,设置所有内容时的艰苦工作非常有用,因为可以将所有内容导出到Swagger,以便其他人可以使用它为它生成不同的SDK.

你的想法是什么？您通常使用Lambda Proxy还是普通的Lambda集成？你喜欢什么,为什么？

编辑:到目前为止,我倾向于总是选择不使用代理功能,因为提到的原因(解耦和说明依赖关系 - 标题,状态代码等 - 预先).

Answer 1

看来AWS 建议为新的API开发选择Lambda代理集成。

注意

Lambda定制集成（以前称为Lambda集成）是一项旧技术。我们建议您对任何新API使用Lambda代理集成。有关更多信息，请参阅使用Lambda代理集成构建API网关API。

我知道，使用代理集成而不是自定义集成来提升API端点和lambda集成的速度（短期内）是很“快”的，但是我很惊讶这是今后所有 API / Lambda开发的建议：

• 我将API Gateway描绘为负责处理“ HTTP详细信息”。使用代理集成可将责任（至少是其一部分）强加给Lambda函数。（即知道如何解释和确定HTTP标头，查询参数，状态码等）
• 在这样做时，我觉得这使支持Lambda函数的职责变得模糊了-Lambda现在既要处理被调用要执行的任何“业务”逻辑，也要处理解释传入的HTTP值并决定传出的HTTP响应价值观。
• 当然，您可以实现一个附加的Lambda函数层来抽象HTTP详细信息，但这不是API Gateway应该做什么？
• 它减少的能力，再利用任何给定的lambda函数在上下文其他比服务的HTTP请求，除非非HTTP客户格式化请求，就好像它是一个HTTP请求。

Answer 2

没有代理。

我在生产中部署了多个 SLS，其中一些产生收入，一些作为内部工具。我完全不使用代理。我不想在我的应用程序中依赖 AWS 的结构，因此如果我们不再是朋友，我可以轻松迁移。

至于代理的优点，我将它们视为缺点，因为感觉你也有，而缺点则是优点。我以前已经看过这一切“让我们移动得超级快”。是的，我们需要敏捷并快速行动，但不能以牺牲思考为代价。我一直和我的工程师们讨论这个问题，文档/设计不足是一回事，另一回事就是说“规划太疯狂了，让我们只编码”。无论您进入市场的速度有多快，这就是您将自己逼入绝境的方式。在没有代理的情况下（以及对项目结构的一些早期规划，也许还有一些良好的 DDD 思维），如果世界崩溃，从 AWS 迁移出来是非常简单的。

除此之外，我发现让新员工跟上 AWS 的速度是非常困难的。一旦你知道这一切都是肉汁，但开发人员就是开发人员，而不是基础设施工程师（我们中同时从事这两种工作的人非常罕见）。当人们开始令人畏惧的兔子洞之旅时，抽离注意力可以帮助他们提高工作效率。我宁愿我的编码员代码也不愿每 20 分钟就 CFN 来打扰我。