[POC] feature: manage stack mappings to unblock api expansion over time

[alharris-at]

Description of changes

Thinking about how we can mitigate some of the Multiple resolvers cannot be attached to a single field issue, I was thinking about whether we may want to provide additional utilities to help customers manage stack mappings.

In my head the problems basically fall into this category.

1. I am migrating between GQLv1 and GQLv2, and the addition of many AWS::AppSync::FunctionConfigurations resources is causing me to hit my stack limit.
2. I am introducing relationships between models, causing my ConnectionStack to swell based on new tables, resolvers, and functions.
3. I am incorrectly trying to use StackMappings (or the system is on my behalf) migrate a resolver between stacks (which I have confirmed with the AppSync team is not feasible, they have no workaround other than detaching in iterative deploys, which we don't want to do).

In light of those three use-cases, I'd propose we vend a new utility (or set of utilities, as this is modelled right now) which make looking into my #current-deployed-backend and current proposed changes and freezing or assigning new resources in the StackMapping section of the transform.conf.json file.

In my mind, the flow could go something like:

1. amplify pull (ensure I have the latest view of the world).
2. amplify api snapshot-stack-mappings (freeze the current state of stack mappings into my transform file.
3. Make changes to my schema.
4. amplify api assign-stack-mappings --stack-name <Blah>
5. amplify push

This is a pretty involved flow, and in reality we can probably just consolidate the snapshot/assign separation, I'd just POC'ed them up separately initially.

Ultimately, if we allow consistently and correctly migration functions between stack, but not resolvers, then we might actually just want to change this functionality to be focused on that, but during my investigation it did not appear that the StackMappings correctly work on the FunctionConfiguration objects today, so that'll need to be something we fix as well I think.

CDK / CloudFormation Parameters Changed

N/A

Issue #, if available

#32

Description of how you validated changes

Currently just testing manually in a test app. Need to add unit and E2E tests.

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)

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