Open sisygoboom opened 5 months ago
Have you seen this?
Thank you
@kekami It looks like that guide is incomplete and no longer being worked on. While I'm on the subject, I tried to implement the existing guide, and it seems to use a hacky workaround that isn't well supported by the current code's design. It does not generate client code for Flutter (it generates .ts instead of .dart), nor does it mention how to authorize the function to perform dynamodb:Query, for example as that is no longer automated.
Hey,👋 thanks for raising this! I'm going to transfer this over to our API repository for better assistance 🙂
Environment information
Description
Hi, the data modelling is currently great for getting started, and the automatic graphql client code generation stuff is terrific.
In the future, I foresee applications maturing and deciding to go down the route of single table design for low cost and high performance at scale.
Since a single table is the AWS recommended way of using dynamodb once access patterns are clearly defined, I'm surprised that it is not supported in Amplify gen 2. At least allowing people to say hey, these models should all be on the same table would be a massive leap forward as that would allow for manual composite key management.
Please see this implementation for an idea of what I'm proposing.