My Pain with AWS Amplify

AWS Amplify is a set of tools and services to build full stack applications based on AWS.
Its CLI helps to integrate and manage different AWS services with your frontend or mobile techstack such as React or Flutter.
This is key when integrating AppSync for GraphQL or Cognito for authentication.

I've been working with AWS Amplify for quite some time and must say that in the beginning I was more cursing than loving it.
Here are my pains and learnings I had with Amplify.

Monorepo but not

Let's say you create a React app by following this tutorial.

You have setup the Amplify CLI, had run npx create-react-app react-amplified and amplify init to integrate your React app with AWS Services.

Now, you would be able to run amplify add api to create a REST or GraphQL API. REST is possible with API Gateway and a Lambda or Fargate (since v6.0.0) whereas GraphQL could be set up with AppSync or Fargate.

This gives you a lot of flexibility and in theory you could create a different tech stack for each endpoint.

You could argue that this is sort of a Monorepo as you have your React app and your APIs wrapped in its own packages.
However, sharing models or libs without manual tweaks is not possible (check out the next part of my series 😉).
That could lead to different versions when using libs like _lodash and harm your local storage as you always have an individual node_modules for each function.

Fortunately, the CLI synthesizes and orchestrates your project 👌

Personal Recommendation: Use PNPM for all your JS-projects. That is not just faster but more efficient. Your machine will be thankful 😜

Folder Bash

As above mentioned, you could create for each endpoint its own tech stack.

However, when doing so, you end up with a lot of folders and files. That could bloat your setup and your IDE when clicking through files.

And if you create a REST endpoint with API Gateway and Lambda, Amplify will create folders within api and functions. The weird part is that you could name them differently... 🤪

Fortunately, Amplify knows that the function is tightly coupled with an API but you as a developer may not 🤔

Personal Recommendation: A good structure is key and you should name your backend services appropriate so that others may understand what's inside. Also name your function like your endpoint or at least mark them with something you may identify later.

Adding other AWS Services

For our use case, we needed to setup an SQS-queue.
Unfortunately, the CLI does not support creating queues (yet) without modifying the Cloudformation- files.

This is how I bootstraped an SQS-queue to our project:

// in amplify/backend/backend-config.json
// many other Resources
"queues": {
  "my-queue-name": {
    "service": "SQS",
     "providerPlugin": "awscloudformation"
    }
 }
// many other Resources
}

and then creating a new folder structure

amplify
  \backend
    \queues
      \my-queue-name
        parameters.json
        template.json

template.json is a CloudFormation template, and parameters.json is parameters file that will be passed to the cloudformation template.

I got heavily inspired by Bardia's article

Hello Json

In addition to the above mentioned point, you probably noticed the .json- files which each folder will have. Those are the configuration files for Amplify. You can also put in your own Cloudformation template (CFN) in order to spin up the service.

However, it can only use json- Format, which is (in my opinion) more error-prone. Or if you want to integrate your own yaml- CFN that wouldn't work and you need to convert it to json.

Luckily, there are tools for that.

Personal Recommendation: Put a diagram and a README.md in each folder. That would document your code and other developer would understand the purpose faster.

Removing is super dangerous

I had a situation where I created a function and then realised I misconfigured it. So I did amplify remove function.
That deleted the whole folder and me as an idiot did not save the code😱

Personal Recommendation: So pay attention when removing functions or APIs❗️❗️ Commit your code if you think it might be useful later.

Costs

Appsync is quite expensive 😱

The time when I was developing it (in August) it already costs me $32.74 and for September when I was not developing on it, it was $31.68. For me as a private person, definitely too much.

Personal Recommendation: Pay attention when you just want to play with it. Depends on your use case and if you really want to use AWS GraphQL Serverless service, but maybe you should consider host it yourself or use services such as Hasura.

Conclusion

Amplify is a great tool and it is nice to integrate your Frontend or Mobile tech with AWS Services and turn it to a fullstack application.

However, I think you could easily bloat up your application and it can get messy real quickly.
The key is to organise and structure your code base. Plus, you should make that aware for other developers by proper documentation.

Still, Amplify does many things good and I can see the value of it.

In my next part of this series, I will add Typescript- functions and turn the function- folder to a Monorepo.

Hope to see you there!