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

Question

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

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

Answer 1

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

优点

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

缺点

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

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

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