Amplify-cli: Amplify CLI Should Manage Multiple GSI Creation and Removal Automagically

[ryanhollander]

Forgive me if this already requested.

Is your feature request related to a problem? Please describe.
This issue and the way it is handled in the CLI today is frustrating, and makes some deployments difficult. It would be better if the developer could define some preferences and have the CLI automatically handle the multiple modifications and steps to successfully transition multiple GSI changes from one environment to another.
https://github.com/aws-amplify/amplify-cli/issues/922

Describe the solution you'd like
1 ) There should be a default configuration that the develop can change with at least two options:
a) never mange multiple GSI changes automatically
b) always manage multiple GSI change automatically

When a graphql change is published where a @key or @connection has changed and requires one or more GSI removals and additions, if the developer has configured as b) the amplify CLI should handle the multiple runs and configurations needed to accomplish the change: first removing GSI's marked for removal, then adding GSI's marked to add. Changes to GSI's should be automatically queued as a remove + add.

Describe alternatives you've considered
I imagine the alternative is changing Cloudfront or DynamoDB to handle this use case better internally. I could also script my own solution. For now I handle it manually when it comes up.

Additional context
see issue 922.

[houmark]

Yes, I think it's unrealistic to have these core services updated to allow multiple GSI's at the same time. DynamoDB has many limitations and that may be due to the insane scale it can do.

But that does not mean the CLI cannot be smarter and do several runs and wait for each GSI to finish before applying the next one. One flow could be detecting when multiple runs are required (better than now where it sometimes misses a potential issue resulting in a rollback). The CLI will then inform the user that this push requires multiple runs to comply with DynamoDB requirements of adding GSI's and that this will slow down the push as it needs to wait for each GSI to be deleted/created. If the developer does not want to do that, he can stop the push/process and manually adjust, but that would rarely be wanted I think.

Of course the amplifyPush --simple in the Amplify Console would have to handle this automatically and just run multiple runs as there's no option for user interaction.

[CodySwannGT]

I can't thumb this up enough. This is such a nightmare on a monthly basis.

1) Add features to development environment
2) Merge to staging
3) Try to deploy
4) Massive manual fixing
5) Gets staging to work
6) Merge to production
7) Try to deploy
8) Massive manual fixing

I mean, I am just stunned that Amplify has added stuff like Textract, etc that are sprinkles on the cake while the batter is poisonous.