时间戳

首页 > 解决方案 > AWS AppSync 解析器 Lambda 函数与速度模板语言 (VTL)

amazon-web-services - AWS AppSync 解析器 Lambda 函数与速度模板语言 (VTL)

问题描述

我一直在研究 AWS AppSync 以创建一个以 DynamoDB 作为数据存储的托管 GraphQL API。我知道 AppSync 可以使用 Apache Velocity 模板语言作为解析器从 dynamoDB 获取数据。然而，这意味着我必须在编程堆栈中引入一种额外的语言，所以我更愿意用 Javascript/Node.js 编写解析器

使用 lambda 函数从 DynamoDB 获取数据有什么缺点吗？有什么理由为解析器使用 VTL 而不是 lambda？

标签： amazon-web-servicesaws-lambdagraphqlaws-appsync

解决方案

使用 lambda 函数作为 AppsSync 解析器有利有弊（尽管请注意，您仍然需要从 VTL 调用 lambda）：

优点

  • 更容易编写和维护
  • 更强大的编组和验证请求和响应
  • 通用功能可能比 VTL 更干燥（不支持宏）
  • 更灵活的调试和日志记录
  • 更容易测试
  • 提供更好的工具和棉绒
  • 如果您需要long在 DynamoDB 表中支持整数（DynamoDB 数字类型确实支持long，但 AppSync 解析器仅支持 32 位整数。如果您使用 lambda，例如通过在通过AppSync 解析器层）- 请参阅（当前）打开功能请求：https ://github.com/aws/aws-appsync-community/issues/21

缺点

  • 每次调用的额外延迟
  • 冷启动 = 更多延迟（尽管如果这对您的用例来说是个问题，通常可以通过保持 lambda 温暖来最小化）
  • 额外费用
  • 每个 lambda 的额外资源，消耗固定的 200 限制

如果您正在执行简单的普通 DynamoDB 操作，那么值得尝试使用 VTL。AWS 的文档对此非常有用：https ://docs.aws.amazon.com/appsync/latest/devguide/resolver-mapping-template-reference-dynamodb.html

如果您正在做一些稍微复杂的事情，例如编组字段、循环或通常 hacky 的非 DRY 代码，那么如果您对额外的延迟和成本感到满意，那么 lambdas 绝对值得考虑以提高编写和维护代码的速度.

推荐阅读