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?