Lambda集成与Lambda代理：优缺点

Question

您认为在AWS API网关中使用具有和不具有代理功能的Lambda集成的优点和缺点（更具体地说，使用无服务器框架时）如何？这是我觉得到现在为止：

LAMBDA集成代理

• 临：人们可以快速原型和代码，而不必担心所有需要的配置细节（和重塑几个轮子像通用模板映射等）。
• Pro：它很容易返回任何状态码和自定义标题，同时还有一种通用的方式来读取请求的主体，标题，参数。
• Con：一切都在代码中完成，所以自动生成文档有点困难。代码中依赖项（标题，模型，返回的状态代码）“隐藏”。

LAMBDA集成，而不代理

• 精读：涉及很多工作更来进行设置，这样的配置可能在不同的资源进行复制。
• Pro：它允许解耦lambda接收和返回的内容，以及它如何映射到不同的HTTP状态码，标题和有效载荷。
• Pro：非常有用，因为它规定了它返回的内容，以及它在标题和有效载荷方面的要求。
• 专业版：从长远来看，设置所有内容时的辛勤工作很有用，因为可以将所有内容导出到Swagger，因此其他人可以使用它为其生成不同的SDK。

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

编辑：到目前为止，我倾向于总是选择不使用代理服务器的功能，由于所提及的原因（解耦，并说明依赖-headers，状态码，etc-前期）。

Answer 1

没有代理。

我在生产中有几个SLS部署，有些产生收入一些作为内部工具。我专门使用没有代理。我不想依赖于我的应用程序的AWS结构，所以如果我们不再成为朋友，我可以迁移而不会有太多的痛苦。

至于代理人的优点，我会认为他们是缺点，因为它感觉你也有，而且是专业人士。在“让我们超级快速移动”之前，我已经看到了这一切。是的，我们需要敏捷并迅速行动，但不以牺牲思维为代价。我始终与我的工程师们共同完成这项任务，其中一件事情就是在文档/设计方面低下一切，一起说“对规划的要求只是代码”。无论你上市速度有多快，这就是你如何摆脱自己的问题。如果没有代理服务器（并且对项目结构进行了一些早期规划，也许有一些DDD思想很好），如果世界变得炙手可热，那么它很容易从AWS迁移出去。

除此之外，我发现使用AWS的东西很难获得新的机器人。一旦你知道它的所有肉汁，但开发人员是开发人员，而不是基础设施工程师（我们这些人谁都是惊人的罕见）。抽象的离开帮助人们在开始拉博索尔的艰难旅程时具有生产力。我宁愿使用编码器代码，也不需要每隔20分钟就打扰一下CFN。