AWS放大-应用同步

Question

当通过Amplify CLI初始化新的GraphQL后端时，示例模式使用@Model注释定义多个类型。比如说...

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")
}

推送时，将创建多个DynamoDB表（每个模型一个）。因此在本例中，创建了三个单独的DynamoDB表（blog、post和Comments）

在我们的例子中，我们有一个Users模型，我们将有20个左右的小集合与用户关联。当感觉这些小集合都属于单个表中的用户对象时，我对不得不管理20个不同的DynamoDB表感到不安。

从我所读到的一切来看，AppSync似乎鼓励使用多个表。例如，AWS AppSync文档下面的屏幕截图中的注释特别指出，博客评论应该放在生产环境中的一个单独的表中。

这与DynamoDB文档中列出的最佳实践相矛盾：

您应该在DynamoDB应用程序中维护尽可能少的表。大多数设计良好的应用程序只需要一个表。

使用AppSync时，每种类型都属于单独的DynamoDB表，这是真的吗？

Answer 1

使用AppSync时，每种类型都属于单独的DynamoDB表，这是真的吗？

不，可以使用单个表存储服务所需的不同类型（或实体）。只要您为将在服务中使用的数据定义了良好的访问模式，您就可以只使用一个表。然而，这种方法可能有点不灵活，因为您必须事先考虑您的访问模式，并且将来很难添加新的访问模式。

目前没有办法利用放大器中的@Model指令来进行这样的配置。您必须手动创建表，然后相应地为每个Appsync类型设置解析器，以便相应地查询/更改。

这是一篇很好的文章，解释了这种方法：从关系数据库到单个DynamoDB表：一步一步的探索

Answer 2

正如您所提到的，DynamoDB文档建议“大多数设计良好的应用程序只需要一个表”。当开发人员在一段时间内了解了他们的数据访问模式，确定了数据模型，并且有一定的规模需求需要优化时，这对于许多应用程序都是有效的。许多开发人员从第一天起就对他们的应用程序没有这种程度的了解，或者不一定有相同的需求。此外，单表设计演示文稿中提到的一些要点（例如，存储成本与计算成本之间的权衡）可能是主观的，具体取决于您的应用程序。

当您正在构建一个新的应用程序或不知道自己的数据访问模式时，使用单表设计模式的好处会逐渐减少，而多表策略则更加灵活。

AWS amplify是一个固执己见的客户机框架，为具有不同规模和复杂性的开发人员提供了合理的默认值，因此，在以最基本的形式利用@model transformer时，它采用了多表策略。随着需求的发展，您可以通过使用Transformer的其他功能（如@key（用于创建单表索引和复合键）甚至全文搜索）来扩展此设计

我们确实认识到，大型或成熟的应用程序可能受益于单表方法。从多个表到单个表可能是一次“合并”操作，在原型阶段之后，并且开发人员已经理解了数据访问模式。事实上，并没有一种“一刀切”的方法，这就是为什么Amplify的GraphQL Transformer可以根据应用程序的发展状况为您提供不同程度的灵活性。

正如Luis在另一个回答中提到的：AWS AppSync支持任何类型的表结构，独立于GraphQL Transformer生成模式。即使您有多个表，也可以通过模式设计、嵌套解析程序甚至实现管道解析程序在单个客户机请求中轻松实现GraphQL关系模式。

（此回复是在Richard的帮助下编辑的）