Aws lambda Lambda集成与Lambda代理：优缺点

您认为在AWS API网关（更具体地说，在使用无服务器框架时）中使用Lambda集成（带代理功能和不带代理功能）的优缺点是什么？以下是我到目前为止的想法：

Lambda与代理集成

• Pro：您可以快速创建原型并编写代码，而无需担心所有需要的配置细节（以及重新设计一些轮子，如通用模板映射等）
• Pro：返回任何状态代码和自定义标题都非常容易，同时还有一种读取请求正文、标题和参数的通用方法
• Con：一切都是在代码中完成的，因此自动生成文档有点困难。依赖项（标题、模型、返回的状态代码）在代码中“隐藏”

无代理的Lambda集成

• Con：需要进行大量的设置工作，并且此配置可能会在不同的资源中重复
• Pro：它允许将lambda接收和返回的内容以及它如何映射到不同的HTTP状态代码、头和有效负载解耦
• Pro：非常有用，因为它预先规定了它返回的内容，以及它在标题和有效负载方面需要什么
• Pro：从长远来看，设置所有内容时的艰苦工作都是有用的，因为一个人可以将所有内容导出为招摇过市，所以其他人可以使用它生成不同的SDK

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

编辑：到目前为止，我倾向于选择不使用代理功能，原因如下（解耦和声明依赖项-标题、状态代码等-预先）。

没有代理

我在生产中部署了多个SLS，一些作为内部工具产生收入。我没有专门使用代理。我不想在我的应用程序中依赖AWS的结构，因此，如果我们不再是朋友，我可以不费吹灰之力地迁移

至于代理的利弊，我会认为他们是骗子，因为你觉得自己也是个骗子。我以前看过“让我们行动得超快”。是的，我们需要敏捷，行动迅速，但不能以思考为代价。我一直和我的工程师们在一起，一件事是缺乏文档/设计，另一件事是一起说“疯狂的计划，让我们只编写代码”。无论你以多快的速度进入市场，你都会因此而陷入困境。由于没有代理（以及对项目结构的一些早期规划，也许还有一些好的DDD思想），如果世界发生变化，从AWS迁移出去非常简单

---

除此之外，我发现很难让新的董事会跟上AWS的步伐。一旦你知道了这一切，一切都很重要，但开发人员是开发人员，而不是基础设施工程师（我们中同时做这两件事的人非常罕见）。当人们沿着拉比洞开始他们令人望而生畏的旅程时，抽象可以帮助他们提高效率。我宁愿我的编码员代码也不需要每隔20分钟就为CFN烦我。

我们也从代理开始，因为启动和运行一系列函数感觉很快。很快我们就明白了，我们创建了一个与代理强制我们读取输入和写入输出的方式非常紧密的耦合，我们的函数不应该知道这一点，应该有更清晰、更简单的接口。然后，我们想开始用它来编排其中的一些功能。不使用Step函数，而且它们肯定不容易迁移

不再有代理了。

（编辑：如评论中所述，我在2018年提到的AWS术语已被删除。也就是说，我关于Lambda代理与定制集成的想法仍然有效。）

看起来像AWS

注

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

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

• 我认为API网关负责处理“HTTP细节”。使用代理集成将该职责（至少一个子集）强加于Lambda函数。（即知道如何解释和决定HTTP头、查询参数、状态代码等）
• 在这样做的过程中，我觉得它混淆了支持Lambda函数的责任——Lambda现在既需要处理调用它来执行的任何“业务”逻辑，也需要处理解释传入的HTTP值并决定传出的HTTP响应值
• 当然，您可以实现一个附加的Lambda函数层来抽象掉HTTP细节，但这不是API网关应该做的吗
• 它降低了在除服务HTTP请求之外的上下文中重用任何给定Lambda函数的能力，除非非HTTP客户端将请求格式化为HTTP请求

因为主体映射模板-代理更好。

我不喜欢body mapping模板，因为在导出的Swagger中它是转义的，例如：

uri:“arn:aws:apigateway:us-east-1:dynamodb:action/UpdateItem”
响应：
违约：
状态代码：“200”
请求模板：
application/json:{\n\“TableName\”：“快乐营销者”，\n\“键”\
：{\n\'pk\'：{\n\'S\'：\'project\'\n}\n\
\\'sk\'：{\n\'S\