tbh, at this point, I think SLS has made better architecture and design decisions than Amplify.
Amplify does a little bit too much and looks like was not designed with a clear / clean, real world, infra and architecture/design, in mind. I’m sure it will get better over time ( as been the pattern with all other AWS services and products )
My problem #1 with Amplify is that if you decide to use it for both Backend and Frontend it will magically create your BE and ties it to your FE, which is awesome but totally impractical in real-world use-cases! in most of my projects I have multiple clients consuming the same BackEnd, sometimes even 3rd party clients, and a lot of them are not, currently, supported by Amplify ( like Flutter for instance ), making it unnecessarily difficult and complicated to use the BE elsewhere ( It’s usable, you just need to find what has the “magic” done and discover BE resources, which brings me to problem #2 )
Problem #2 is even worse in terms of good practices in architecture and design, I’m an SA which makes me hesitant about some of the opinions of Amplify, especially if used for both BE and FE. and that’s the separation of concerns! while this may be helpful (arguably) for beginners or really small apps that exist only in one platform ( ie, mobile ) and has simple/1to1 BE/FE relations, it can turn into a nightmare if used in enterprise, or even small apps that do just a little bit more than a simple game on app-store. I have many concerns there but in general I really do not like to mix the BackEnd and FrontEnd code the way it’s done in Amplify. I see no good coming out of that! although you can see the separation in different config files, that does not help.
#3 Added complexity! which is the weirdest part, as it looks like Amplify is trying to sacrifice everything else to make it simple for “ideas” to turn into “apps” ( think of FireBase ), but it does it in a very very very opinionated and complex way, if you want to do anything else than the way it was designed for, you may actually need to learn a lot more about its opinions which makes it more complex than standard ways of doing things!
These are all just my humble opinion, and may very well be wrong or changed, but atm if I was to improve Amplify I would completely separate the two sections ( while keeping the automated process to create and connect them, but using distinct / separate commands! ) and would provide support/documentation to plug the created BE to other frameworks and would treat Amplify owns FE just like one of those, not differently.
I would also use best practices and cleaner structural design to store everything that should not be checked into a repository in one .directory and not scattered in different config folders.
I would also try to design a better / simpler infra as a code solution ( not multiple CFs )
I would also try to avoid doing more than what needs to be done by Amplify! so for instance to set-up the local profile for AWS accounts, they could just direct the user to AWS CLI where they can learn to set up their local profiles, or AWS could create a separate tool that does just that, I feel that’s a little bit too much to do all that and create AMIs, opening web-pages and stuff! that makes it difficult to categorize this tool in my tool-set! is it a CD/CI tool? is it a development Framework? is it an IDE plugin? is it a magic wand?
But again, I’m ( almost ) sure it will become much much better over time, but until then, while keeping an eye on it, I’m not going to use it for more than a ready to use user-management UI template for Cognito and will continue using lovely SLS for everything else…