AWS Amplify-AppSync和多个DynamoDB表

Question

在initializing a new GraphQL backend via the Amplify CLI时，示例架构使用@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表（博客，帖子和评论）

在我们的案例中，我们有一个Users模型，我们将与二十个左右的小集合相关联。当感觉这些小的集合都属于一个表中的User对象时，我对于必须管理二十个不同的DynamoDB表感到不安。

从我阅读的所有内容来看，AppSync似乎鼓励使用多个表。例如，AWS AppSync文档下面的屏幕快照中的注意特别指出，博客注释应放入生产环境中的单独表中。

这与DynamoDB documentation中提出的最佳做法相矛盾：

  

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

使用AppSync时，每种类型确实属于单独的DynamoDB表吗？

Answer 1

  

使用AppSync时，每种类型确实属于单独的DynamoDB表吗？

否，您可以使用一个表来存储服务所需的不同类型（或实体）。只要您对将在服务中使用的数据具有明确定义的访问模式，就可以仅使用一个表就可以摆脱困境。但是，这种方法可能不太灵活，因为您必须事先考虑访问方式，并且将来很难添加新的访问方式。

当前无法利用Amplify中的@model指令进行这种配置。您将必须手动创建表，然后为每种Appsync类型相应地设置解析器，以进行相应的查询/突变。

这是一篇很好的文章，解释了该方法： From relational DB to single DynamoDB table: a step-by-step exploration

Answer 2

正如您提到的，DynamoDB文档建议“设计最好的应用程序只需要一个表”。当开发人员逐渐了解其数据访问模式，建立在数据模型上并且具有某些需要优化的规模要求时，这对于许多应用程序都是有效的。从第一天开始，许多开发人员就没有对他们的应用程序有这种了解，或者他们的需求相同。另外，关于单表设计的演讲中提到的一些要点（例如，存储成本与计算之间的权衡）可能会因您的应用程序而有所主观。

在构建新应用或不知道数据访问模式时，使用单表设计模式的好处会减少结果，并且多表策略更加灵活。

AWS amplify是一个自以为是的客户端框架，为具有不同级别的规模和复杂性的开发人员提供明智的默认设置，因此，在采用最基本形式的@model转换器时，它已采用了多表策略。随着需求的发展，您可以通过使用Transformer的其他功能（例如@key（用于创建单个表索引和组合键），甚至使用@searchable从DynamoDB进行全文搜索和流传输来增强此设计。

我们确实认识到大型或成熟的应用程序可能会受益于单表方法。在原型开发阶段之后以及开发人员已经理解数据访问模式之后，从多个表转到单个表可能是一次“合并”操作。实际上，没有一种“万能的方法”，这就是Amplify的GraphQL Transformer为您提供不同级别的灵活性的原因，具体取决于您应用程序在开发过程中所处的位置。

Luis在另一个答案中提到：AWS AppSync确实支持任何类型的表结构，而与GraphQL Transformer生成模式无关。即使您有多个表，也可以使用schema design，nested resolvers甚至实现Pipeline resolvers在单个客户端请求中轻松实现GraphQL关系模式。

（此回复已在Richard的帮助下进行了编辑）