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

Question

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

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

Answer 1

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

优点

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

缺点

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

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

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