AWS Amplify - Pros and Cons.
[Update]: The 2nd part of these series about my Amplify workarounds for issues noted below, while still using its strengths to our advantage is now available here.
These are my humble opinions about the Amplify Framework, which may, very well, be wrong or change at any time!
With that being said, I’d also like to mention, that, I believe, like pretty much everything AWS, Amplify will evolve and get better and better over time, this is just my experience with its current state of being!
Disclaimer: I love and use AWS (a lot of it!) every single day for a long time now and none of my complaints about any of its tools means I don’t recommend or do not like them! For instance, I’m actually using Amplify and want to use it even more and make it even better!
What I really Like:
- The design of the CLI processes and workflows! ( when they work )
It does a good job of providing simple questions following each command with default answers and hints to abstract the complexity of some of the commands ( in comparison to many flags and parameters needed to be passed in other tools like sls ).
- Clear and transparent report and confirmations on changes to be made on the Backend before the fact ( except the first weird
initcommand and when the tool does something even when you say No! )
- Really cool, pain-less, out-of-the-box User Management Flow UI components for React and React-Native! #AWSome!
What I don’t like much:
- It mixes sensitive and public data, and although they try to guard them using
.gitignore, I don’t like the fact that they are scattered everywhere. keeping all local stuff in one directory that could be ignored cleanly, safely and entirely instead of six additional lines in the repositories root
.gitignorewould be a better option imho.
Also, I don’t like that it modifies the project's root
.gitignore. A better design (imho) would’ve been to have one
.gitignorefile in the local directory ( let’s call it
.amplify) that would ignore that directory and everything in it ( including the local gitignore itself ).
amplify inithas remote side effects. Say Whaaaat?!
initinga local library on my local machine will actually create and modify resources on the Cloud. before I commit or push or anything.
Notably, an S3 bucket and an AMI role will be created for no apparent reasons ( imho those can and probably should be created later-on when the user decides to “commit” and/or “push” their changes. ).
- It mixes Backend and FrontEnd, kind of, ( referred as BE & FE onward )
I see what the intention was here, AWS needed to offer an alternative to FIrebase, and that’s fine, they still need to do that though! Firebase was (is) an easy BE for FE developers. as some may say Backend-as-a-Service, BaaS, it will happily free you from BE code/infra and get out of the way, Amplify in the other hand, brings both BE code AND BE infrastructure-as-code to your FE code-base and will stay in the way, all the way.
Also, Firebase is a BE with clients available for many imaginable platforms and use-cases, on the other hand, currently, Amplify does not support all the use-cases in all the platforms, having features and capabilities scattered un-evenly depending on the technology / platform.
- Next, It’s not really clear what is Amplify! it’s doing too much.
It is BE, it’s FE, it has UI components, Scaffolding capabilities, it’s IaC, it’s CI/CD and it’s none of it! it even sets-up your local AWS profiles for you and creates related resources as well when you
amplify configureit for the first time! It could’ve been a high-level tool-chain if it was designed/built a bit more modular and plug-and-play, but when it creates and owns those low-level services ( instead of plugging into them ), I can’t categorize it as such.
There are even over-lapping functionalities between AWS tools itself (like AppSync, Cognito, SAM, and AWS CLI) and Amplify.
- Feels like It’s designed upside down!
Until a few months ago, not more than one person could work on a project inited by Amplify (1)(or on more than one computer) because the generated config files could/should not be checked to VCS and re-initing the same project would’ve created a different project (and different resources on the cloud!). Not only that, but it was, apparently, designed to be this way. so the ability to work in a team was added as a “new feature” and “enhancement” later on. (2) which makes me wonder how was this tool designed?!
I guess when you rebuild something from scratch, you do so, in big part, using what you’ve learned from the previous thing. Aws mobile hub was the precursor for Amplify and yet it did not inherit some of its basic features that I would argue should have been an absolute requirement even in an alpha MVP release.
- Why not SLS? 1 + 1 = 0
Was it designed to be: Firebase + Serverless Framework = Amplify?
If so, it’s neither and none, each of those tools was designed to solve specific problems.
Serverless Framework is a great tool and a joy to work with, it has its own quirks, no doubt, but it is very “well architected” for the most part, and whenever there is something that you may not like, there are easy and accessible ways to change or extend it, it’s open, it’s simple and it’s provider-agnostic. if AWS wanted to offer its own SLS alt, it needs to be better to be able to compete. Amplify is not, it’s ambiguous, it’s complex, not “Well Architected ™ ”, and it’s not provider-agnostic ( Although the
Provider Pluginscategory may be there to address this issue in the feature?)
There are more low-level issues when comparing Amplify with SLS, for instance, serverless makes CloudFormation usable by humans by abstracting it in much simpler and shorter serverless YAML files, but Amplify just hides the auto-generated CloudFormation files (some YAML, some JSON and, unfortunately, some JSON content in YAML files!) deep down in the config folders.
Also, for some reason, it feels much slower and more bloated than SLS ( i said feels because I haven’t measured and compared them side by side)
It also creates much much more resources than SLS.
- The CLI tool is verbose. each command prints a lot of data, most of which is not necessary, cluttering the terminal and making useful information hard to find.
Simplicity is the sign of design maturity.
- Not only your deployments but also your FE code relies on (needs to import) generated files by Amplify which are not supposed to be checked in. making it tricky to have a clean, straight forward CD/CI pipeline.
I assume there may be workarounds for each of these but, again, it was designed upside down, we know for a long time where to get/set the secrets and environment variables. why there? why like that?
- Bugs and glitches. like for instance, When you run the
amplify publishcommand, it will prompt you for confirmation, which is a good thing, except that, if you say No it goes-on and compiles and builds and uploads everything anyway and then happily announces that Your app is published successfully. and is now publically available!
- The User-Mgmnt flow UI components are not top-notch! they could be better, not only in terms of design, quality, and extendability but also functionality. For instance, a user can not log in using their email and password, only user-name and password. Also, the components are available only for React projects. But as a minimum, they are still awesome!
AWS Amplify is a great tool and a must to try for people who are always in-look to get involved with the future before it becomes present!
It has, however, still a lot of room to improve to become a reliable and omnipresent toolchain in FE developers tool-box or being used and adopted by more serious projects.
I’m using it today, in production, for a couple of personal projects and enjoy a few novel concepts in it, I’m however struggling to fit it in the project in a way that does not introduce added complexity and architectural ambiguity to the project. I’m not sure, for instance, if I can hand this project to a team of experienced engineers and expect them to understand what’s going on.
Overall, my expectations are a bit higher as well, because it carries three letters at the beginning of its name, AWS.
Talking to you soon!