Amplify-cli: Add option to specify DeletionPolicy for API category and default to retain for provisioned Data Sources

[jkeys-ecg-nmsu]

Is your feature request related to a problem? Please describe.
amplify push can be a dangerous option if schema.graphql models were erroneously dropped during merges.

Describe the solution you'd like
Give us the option to set the DeletionPolicy for each model (wish list) or at least the entire API stack. This would make amplify push a more forgiving operation because even if the model gets removed from the schema on the AppSync side, it can still be restored without any data loss. I also think this should be the default behavior. In the event that the user truly does want to drop a model/table with data loss, they can switch the DeletionPolicy back to Delete in order to run the amplify push.

Describe alternatives you've considered
Write a custom git pre-push hook that parses the new schema.graphql for all models, then compares that against the list of all Data Sources for that API, and reject the push if it would drop a table.

[houmark]

This is actually a bit scary to think about. One simple * (or a bug in Amplify? Plenty of those) and the production database and its data can be gone with no warnings in seconds. Amplify should default to protect any database table and have the user explicit confirm that they want to delete it on schema changes.

[jkeys-ecg-nmsu]

Seems like this could be implemented on a per-model basis simply by adding one or two new directives, something like this:

@retentionPolicy(retain: true)

Then parse the retain field and inject that into the DeletionPolicy for each model's stack.

[undefobj]

Seems like this could be implemented on a per-model basis simply by adding one or two new directives, something like this:

@retentionPolicy(retain: true)

Then parse the retain field and inject that into the DeletionPolicy for each model's stack.

In general it's best practice to try and keep implementation specific details outside of your datamodel. Not always possible but that's the top level guidance for custom directives. That being said we can look at implementing this in different ways for the whole platform. I've set a tag for this in the backlog.

[jkeys-ecg-nmsu]

@undefobj thank you for the advice and for tagging this FR.

[cyrfer]

Another option is to setup the database separately, with the desired retention policy, then use amplify to setup your API and pass references for the database resources. I think this prevents confusion and easier maintenance. Today this is might be possible by modifying the generated CF templates for the API if you are comfortable with cloudformation, but future implementations of the CLI could make this possible.

I don't love that Amplify API 'owns' the database it interacts with when using the CLI to setup. What if I want to make a feature stack but use the same data 'environment' as my DEV env? Its impossible to share the database when the API stack 'owns' the data stack.