To amplify or not to amplify - My use (and now lack) of amplify

Sep 23, 2019

If you’re looking at building serverless web applications or mobile apps on AWS and you want to get going fast, then AWS Amplify is definitely something you want to have a good look at. One of the questions I was faced with when I was setting out on my endeavor to create the engine that runs this blog was whether or not Amplify was for me - the decision was that it was, at first, and then it wasn’t. Let me take you through the story.

The whole back story goes a fair way back. I started working for AWS back in January of 2018, and when I first started I remember talking to me new colleagues about how I had moved my WordPress blog to run on AWS (as an AWS Elastic Beanstalk app), and one of the guys in the office hit me with “Yeah, that’s cool - but come on, is it serverless?”. Now he meant it in a very tongue in cheek fashion, but it did of course get me thinking - what would a serverless blog on AWS look like? I was pretty sure that I could have done some Google’ing and found info and code from other people who have built headless CMS’s on the platform - but I wasn’t going to learn much by taking someone else’s solution and so I set off on planning this out. You might be asking at this point though “That was a year and a half ago - what on earth took you so long?”, which is a totally fair question, and it ties in to what I wanted to talk about in this post. I started writing this project and then completely canned it for one reason or another twice before I got to the form I’m currently in (this being the third attempt at it). I explored API Gateways and lambda functions, looking at doing them with .net which I was super comfortable with, and then in to nodejs which I wasn’t as deep in at first - and ultimately ended up throwing it in the bin for reasons to do with either performance or code complexity. The latter being super important to me, because if the code base was hard to manage, I likely wouldn’t be able to add features quickly, or more importantly, fix bugs quickly - which would then get in the way of me actually creating content. So when the time came for my third crack at getting this right - I noticed this little thing called Amplify, and this is where the love affair began.

If you’re new to Amplify there are essentially three parts to it that you need to know about:

  1. The Amplify client libraries
  2. The Amplify CLI
  3. The Amplify console

The first two components were where I began, with the console launching at re:Invent 2018 and coming along a bit later for me. The short version is that the CLI makes it very easy to generate application scaffolding that includes CloudFormation to deploy a static web app (or mobile app) that consumes some common AWS services. If you want to add authentication, you just ran amplify add auth and a couple of questions later it was ready to go. Storage? amplify add storage and you’ve got it. This got me very excited, and in the space of a couple of days I had taken myself from nothing to a static website for my back end that was authenticating me as a Cognito user, and was pushing data to and from DynamoDB (via a GraphQL endpoint in AppSync) and S3. If you read my previous post you might recognise those components from my current architecture, and you would be right - what I’m running right now is very close to what Amplify gave me quickly in those first few days. However, if you saw my code today - you won’t find a single reference to Amplify in there at all now.

There was some method to my apparent madness here, and it ended up coming about as I tried to tack things on that were outside of what Amplify supports well. For example - when I needed to look at extra lambda functions that tied in to a CodePipeline and CodeBuild activities to be able to run Jekyll, there wasn’t a simple way for me to extend the CloudFormation that Amplify gave me. This lead to me putting another project along side my existing code which would let me manage the deployment of everything else I would need in CloudFormation to make this vision of mine work. This approach worked for a short while, and I got my initial prototypes up and running from here, but I wasn’t happy with having half of my assets in the amplify project, and the other half in a separate CloudFormation stack for the rest of it. This is ultimately what led me to moving away from the Amplify CLI component in favor of my own CloudFormation project (which I wrote with the CDK - I’ll dive deep on this in future).

At this point I still had all the Amplfy JavaScript libraries in my code - this wasn’t in itself an issue - the code still ran and I could deploy it just fine. What felt weird though is that Amplify usually generated a lot of code in to that for me (notably the aws-exports.js file, which has a lot of configuration in terms of names of resources and URLs that were generated by the CloudFormation, and a lot of the GraphQL elements). After some thought about how I would maintain these independently I decided to pull those out in favor of my own approach. I implemented the Apollo client for the GraphQL components (with queries and mutations that I would now manage myself), and hand coded a bunch of the authentication code using the Cognito library.

For me this is really all about trade offs - which is a common thing in IT architectures, I know it’s a term I use a lot when I’m working with my customers (especially in a Well Architected review). My trade off here was that I would gain the simplicity of having everything in one project, and full control over what I deployed and how it was deployed, but it would come at the cost of me ultimately having more code to maintain because I wasn’t using the stuff Amplify provides. Now in my case I was happy to take that trade off, what I gained for me offsets the cost of what I lost - but that isn’t to say universilly that Amplify isn’t for anyone at all. I would use (and have used) Amplify in other projects I’ve worked on recently because in their cases it made so much sense to get moving quickly and we were working within the boundaries of what Amplify does well. My challenge to you if you’re reading this and you’re wondering if Amplify is for you, is to sit down and really figure it out. Quantify your trade-offs and goals for your project and see if it makes sense, and I’m willing to bet there are still plenty of people out there who will continue to use Amplify and who will be more successful for doing so.

To wrap this up then - Amplify was an awesome way to get me started, and it got me in to GraphQL which put me on to the model that formed the basis for my current architecture, but I found reasons to move beyond what Amplify could offer me in favor of my own code. The trade-off here is that I have more of my own code to manage, but the benefit is that it’s all natively connected in one package now and I have the freedom and control to manipulate any of it whenever I need to. I want to say though that I am absolutely still a fan of Amplify and what it does for AWS developers - it’s a real PowerHouse and gets you moving quickly. If you’re building an app that works within the common use cases that it has native support for you will have a really great experience - I just found for my own use case that it wasn’t quite able to give me the flexibility I needed, so for me the answer was “to not Amplify” as the title of this post asked. Definitely do your own evaluation though about what suits your project and goals though when you’re next kicking off your next serverless project!

 

Comments

You're signed in as | Sign out

Submitting comment...

There are no comments on this post yet. Be the first to leave one!