I’m just reading about https://aws.amazon.com/fr/blogs/mobile/announcing-the-aws-amplify-cli-toolchain/ and I wonder how this is different from SLS.
Of course, SLS is agnostic, so they definitely provide different services, but I wonder when/if we should use aws-amplify in addition of Serverless. Maybe some things are easier with amplify?
I’ve never used aws-amplify, just discovering it and I wonder if it should be part of my tools.
If you’re not using Amplify for your front end then NO.
If you are using Amplify for your front end and you’re currently using Serverless/SAM for your backend then I would continue doing that but keep an eye on Amplify CLI.
If you’re starting a new project and you understand AWS serverless plus the Serverless .Framework/SAM then I would probably continue using Serverless/SAM. Again, keep an eye on Amplify CLI.
If you’re a front end developer starting a new project from scratch who wants to use AWS serverless and Amplify but doesn’t understand much about the backend services then use Amplify CLI.
What’s the difference between Amplify and SLS in terms of functionalities? It sounds like that SLS focuses on building backend services while Amplify covers both frontend and backend?
I’m currently at the same fork in the road. Amplify is impressive in itself and an AWS solution but once checking out this plugin https://github.com/sid88in/serverless-appsync-plugin
I dont see why i would limit myself using amplify instead of serverless, Perhaps im missing something,
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…
Hello friends,
I’m new to the Serverless Framework, with some working experience on AWS Amplify. A lot of progress has been happening on both sides since Feb 2019. Before investing more, curious how the two compare now, a few years after the original question was asked.
Does someone here know of some resources that do a good job at detailing this, perhaps even with examples?