My Pain with AWS Amplify
Tags: aws, amplify, javascript
Published: 2021-10-11 07:30:19

---
series: AWS Amplify
---

[AWS Amplify](https://aws.amazon.com/amplify/) is a set of tools and services to build full stack applications based on AWS.
Its [CLI](https://docs.amplify.aws/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](https://docs.aws.amazon.com/appsync/latest/devguide/what-is-appsync.html) for GraphQL or [Cognito](https://aws.amazon.com/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.

![Amplify Bash](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ghgtfd1qdgk6gbo73bvs.png)


## Monorepo but not

Let's say you create a React app by following this [tutorial](https://docs.amplify.aws/start/getting-started/setup/q/integration/react/).

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](https://lodash.com/) 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](https://pnpm.io/)  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:

```json
// 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

```bash
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](https://medium.com/@navvabian/how-to-add-an-sqs-queue-to-your-amplify-cli-bootstrapped-project-cb7781c636ed)

## 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 😱

![appsync-to-expensive](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/odxs0nygz56zjzv1f4d3.gif)

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](https://hasura.io/).

## 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!