Cbonif/single-table-design

[chrisbonifacio]

Description of changes:

Adds page that goes over single table design in DynamoDB with an Amplify Gen 2 schema example and code snippets

Related GitHub issue #, if available:

Instructions

If this PR should not be merged upon approval for any reason, please submit as a DRAFT

Which product(s) are affected by this PR (if applicable)?

• amplify-cli
• amplify-ui
• amplify-studio
• amplify-hosting
• amplify-libraries

Which platform(s) are affected by this PR (if applicable)?

• JS
• Swift
• Android
• Flutter
• React Native

Please add the product(s)/platform(s) affected to the PR title

Checks

• Does this PR conform to the styleguide?

• Does this PR include filetypes other than markdown or images? Please add or update unit tests accordingly.

• Are any files being deleted with this PR? If so, have the needed redirects been created?

• Are all links in MDX files using the MDX link syntax rather than HTML link syntax?
  
  ref: MDX: [link](https://docs.amplify.aws/)
  HTML: <a href="https://docs.amplify.aws/">link</a>

When this PR is ready to merge, please check the box below

• Ready to merge

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[printSamuel]

Past me (1 week ago) would have loved this!
I'm not sure if this is an officially supported feature, but I think it would be interesting to learn how to use functions like begins_with, greater_than, and between on the sort key.
It works with the "old schema", like this:

export function request(ctx) {
  return {
    version: '2017-02-28',
    operation: 'Query',
    query: {
      expression: 'PK = :PK and begins_with(SK, :SK)',
      expressionValues: util.dynamodb.toMapValues({
        ':PK': ctx.arguments.PK,
        ':SK': ctx.arguments.SK
      }),
    },
  };
}

Thanks for your effort. :)

[chrisbonifacio]

Strange. .query should be a valid method based on the AppSync docs:

https://docs.aws.amazon.com/appsync/latest/devguide/tutorial-dynamodb-resolvers-js.html#configure-query

I didn't run into issues deploying or invoking it in a request from the client side

[johnpc]

why not just .public()? In general I don't like the idea of using api keys in our examples / docs because they're a time bomb that causes customer projects to break in the future. Since the default npx create amplify includes the auth category, I think it's safe to use everywhere in our docs.

[johnpc]

The language makes me wonder why typical Amplify UX does it the "unnecessary and inefficient" way. It might be worth exploring the tradeoffs of taking this approach. Or, if we really believe this is a superior approach, we should consider adding this feature more natively into our L3 constructs and client libraries.

[sisygoboom]

It's not widely used partly because:

1. Few people know it exists; Amazon, for whatever reason, hasn't made a huge effort to promote it despite using it themselves on amazon.com.
2. You must define your access patterns upfront; many new projects prefer flexibility over efficiency.
3. It can cause problems if you don't know what you're doing. Having everything on one table is undeniably better, but for novices, wrapping their heads around partitions and profile details, sharing the same virtual space as order history, for example, might be confusing.
4. Denormalisation: This pattern sometimes requires repeated data, which can be challenging considering most people are familiar with relational normalised data.

That being said, it would be nice to see some native code for it, most people who follow this pattern currently define a table externally and use ElectroDB within a lambda.