AWS Amplify - AppSync &多个 DynamoDB 表 [英] AWS Amplify - AppSync & Multiple DynamoDB Tables
问题描述
当
这与 DynamoDB 文档:
<块引用>您应该在 DynamoDB 应用程序中维护尽可能少的表.大多数设计良好的应用程序只需要一张表.
使用 AppSync 时，每种类型都属于单独的 DynamoDB 表是否真的如此?
正如您所提到的，DynamoDB 文档建议大多数设计良好的应用程序只需要一个表".当开发人员随着时间的推移了解他们的数据访问模式、确定数据模型并具有需要优化的特定规模要求时，这对于许多应用程序是有效的.许多开发人员从第一天起就对他们的应用程序没有这种程度的理解，或者不一定是相同的要求.此外，关于单表设计的演示文稿中提到的一些要点(例如，存储成本与计算之间的权衡)可能会根据您的应用而具有主观性.
当您正在构建一个新应用程序或不知道您的数据访问模式时，使用单表设计模式的好处会减少结果，而多表策略则更加灵活.
AWS amplify 是一个固执的客户端框架，为具有不同规模和复杂性级别的开发人员提供合理的默认值，因此它在以最基本的形式利用 @model 转换器时采用了多表策略.随着您的需求的发展，您可以通过使用 Transformer 的其他功能来增强此设计，例如 @key(用于创建单表索引和复合键)甚至全文搜索&使用 @searchable 从 DynamoDB 流式传输.
我们确实认识到大型或成熟的应用程序可能会受益于单表方法.从多个表到单个表可能是一次合并"操作，在原型设计阶段之后，并且开发人员已经理解了数据访问模式.实际上，并不存在一刀切"的方法，这就是为什么 Amplify 的 GraphQL Transformer 会根据您的应用在发展过程中所处的位置，为您提供不同级别的灵活性.
正如 Luis 在另一个回答中提到的:AWS AppSync 确实支持任何类型的表结构，独立于 GraphQL Transformer 生成模式.即使您有多个表，您也可以使用 模式设计，嵌套解析器，甚至实现 管道解析器.
(此回复在 Richard 的帮助下进行了编辑)
When initializing a new GraphQL backend via the Amplify CLI, the sample schema defines multiple types with the @model annotation. For example...
type Blog @model {
id: ID!
name: String!
posts: [Post] @connection(name: "BlogPosts")
}
type Post @model {
id: ID!
title: String!
blog: Blog @connection(name: "BlogPosts")
comments: [Comment] @connection(name: "PostComments")
}
type Comment @model {
id: ID!
content: String
post: Post @connection(name: "PostComments")
}
When pushed, this results in the creation of multiple DynamoDB tables (one per model). So in this example, three separate DynamoDB tables are created (Blogs, Posts, and Comments)
In our case we have a Users model and we're going to have twenty or so small collections associated to the user. I feel uneasy about having to manage twenty different DynamoDB tables when it feels like these small collections all belong with the User object in a single table.
From everything I'm reading it seems like AppSync is encouraging the use of multiple tables. For example, the Note in the screenshot below from the AWS AppSync documentation specifically calls out that the blog comments should go into a separate table in a production environment.
This contradicts the best practice laid out in the DynamoDB documentation:
You should maintain as few tables as possible in a DynamoDB application. Most well designed applications require only one table.
Is it truly the case that when using AppSync each type belongs in a separate DynamoDB table?
As you mentioned, the DynamoDB documentation suggests that "most well designed applications only require a single table". This is valid for many applications when developers have learned, over the course of time, their data access patterns, settled on a data model, and have certain scale requirements that need to be optimized. Many developers do not have this level of understanding of their application from day 1 or necessarily the same requirements. Additionally some of the points mentioned in the presentations on single table design (e.g. tradeoffs between storage costs vs compute) can be subjective based on your application.
When you are building a new app or do not know your data access pattern, the benefits of using the single table design pattern has diminishing results and the multiple tables strategy is much more flexible.
AWS amplify is an opinionated client framework providing sensible defaults for developers who have different levels of scale and complexity, as such it has adopted a multiple table strategy when leveraging the @model transformer in its most basic form. As your requirements evolve, you can augment this design by using additional features of the Transformer such as @key (for creating single table indexes and composite keys) or even full text search & streaming from DynamoDB with @searchable.
We do recognize that large scale or mature apps might benefit of a single table approach. Going from multiple tables to single table is probably a one time "merge" operation, after the prototyping phase, and when data access patterns have been understood by the developer. In reality there is not a "one size fits all approach" which is why Amplify’s GraphQL Transformer gives you different levels of flexibility depending on where your app is at in its evolution.
As Luis mentioned in another answer: AWS AppSync does support any type of table structure independent of the GraphQL Transformer generation pattern. Even if you do have more than one table, you can easily implement GraphQL relational patterns in a single client request either with schema design, nested resolvers, or even implementing Pipeline resolvers.
(this response was redacted with the help of Richard)
这篇关于AWS Amplify - AppSync &多个 DynamoDB 表的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
