Amplify-cli: Replace CLI walkthroughs with a "single source of truth" config file.

[potatopotaro]

Is your feature request related to a problem? Please describe.
In my opinion, lengthy and complex CLI walkthroughs lead to poor dev UX.

More specifically, they tend to obscure documented bugs with copy-pastes of walkthroughs, which only get more and more outdated. In addition, as of now, they don't 100% consistently keep the previously selected value/result (when using amplify update) leaving us vulnerable to overwriting what we've already configured. There are likely more cons that I haven't described here.

Describe the solution you'd like
I'd love to use a single config file or perhaps a directory of specifically named config files (e.g. analytics.json). Something very similar to the already existingbackend-config.json, but obviously with more detail and capabilities, would be ideal.

In addition, it'd be nice if the amplify project could rely heavily on this config file(s), to the point where I could look to it as the "single source of truth" for my amplify project. Currently, there are a multitude of locations I have to look in when I debug (e.g. backend-config.json, amplify-meta.json, aws-exports.json, team-provider-info.json, cloudformation files, etc.) and while it may be impossible to eliminate the need to check all of these locations, it'd be nice if logic such as the dependsOn key/value in backend-config.json and amplify-meta.json could be consolidated into one file.

Additional context
I've been forced into several occasions where I've had to delete either the entire amplify project or remove categories because of bugs I've run into during update walkthroughs. This post is largely due to these incidents.

I mean no offense to the amplify team, I love what I've been able to build with Amplify so far and I appreciate all their hard work.

[rrrix]

+1 - Completely agree! Great idea!

Interactive CLI walkthroughs are NOT automation friendly.

Sure, they're good if this is your first Amplify project, but once you're a seasoned Amplify CLI & Toolkit developer and you have to actually build, operate and maintain a complex project, they just get in the way and slow down developer productivity and velocity.

[undefobj]

Have you checked out Headless Mode? This is effectively the same as a config file and is used for automation, including the CI/CD that the Amplify Console uses.

[potatopotaro]

@undefobj Thanks for the tip. I looked into Headless Mode, and while it does aid CI/CD, it appears to simply be a set of flags for pre-emptively answering the walkthroughs. Thus, Headless Mode is still exposed to walkthrough logic and bugs. In my opinion, writing bash scripts isn't a great experience syntactically. In addition, the scripts are largely for declaration/instantiation, they contain little to no useful info about existing amplify project state. If anything, I believe the scripts could be harmful if devs aren't thoroughly aware of existing state.

Headless mode aside, I'm currently stuck on a bug where I cannot amplify remove my notifications category. I believe this is occurring due to the logic/conditional-checks in the amplify remove notifications walkthrough.

All I want to do is remove the notifications category from my amplify project, however, the walkthrough prevents me from doing this as it is erroring out on the fact that the respective Pinpoint instance no longer exists. In addition, if I delete the appropriate notifications and analytics config code from amplify/backend, amplify status/push will list the Operation for the Notifications category as Delete (as expected). However, running amplify push results in no change, and I will continue to see the Notifications operation set to Delete. I wish my changes to the configs in amplify/backend were respected and resolved absolutely by amplify push.

I've been using Amplify for 9 months now. I've run into many limitations/bugs regarding the walkthroughs and deployment process (amplify push), that I've had to resolve by entirely removing and re-adding categories. I understand that the existence of bugs is to be expected. However, I believe giving walkthroughs "first-class" status and leaving direct config changes as a "secondary" or "backup" approach will only lead to more bugs/limitations.

Sorry for the long response/rant 😅

If anybody from the amplify team (e.g. product manager) is curious about my experience with Amplify, I'd love to share it over a call. Amplify is immensely valuable to me and I'd love to help in any way I can.