amplify-category-api

amplify-category-api copied to clipboard

Description of changes

Allow overwritable DynamoDB table name

Issue #, if available

N/A

Description of how you validated changes

1. Test in sample app

Checklist

• [x] PR description included
• [x] yarn test passes
• [x] Tests are changed or added
• [x] Relevant documentation is changed or added (and PR referenced)
• [x] New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies
• [x] Any CDK or CloudFormation parameter changes are called out explicitly

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

@pavinthan - overriding the table name like this could be tricky to maintain long-term. Are there alternatives, you've potentially explored using the amplifyApi.resources.cfnResources?

Separately, we're currently working on a feature to allow you to describe you model but "point to an existing DynamoDB table". I think that might setup the same use case as you're trying to solve here.

@renebrandel, thanks for the feedback! I’m excited about the feature to link models to existing DynamoDB tables, but I still see a unique value in allowing custom table names right from the start—especially for new projects without existing tables. This avoids the need for additional CDK apps or tools.

On the concern about name conflicts across different environments, like multiple sandboxes in the same region, I suggest leveraging the cfnTables in cfnResources. We could allow users to include Amplify-specific identifiers (appID, branch name, sandbox identifier, and environment name) from defineBackend in their table names. This would enable a flexible yet standardized naming convention.

Incorporating this feature would give us tighter control over resource naming from the get-go, making projects easier to manage as they grow.