Be(a)ware - AWS Amplify does not have migrations

This post is about the tool / framework AWS Amplify - provided by Amazon itself to work with most of the popular AWS services - when working on serverless web applications.

A word of caution if you are planning to use this tool for your new project - While this tool has many problems, one issue that I face recurrently is that this does not have "migrations" in it - yeah like the "migrations" on a database. Let's understand what that means in the context of AWS Amplify.

Firstly, know that amplify has support for teams. One can create new "environments" specific to their use case and work exclusively in their environment before they decide to merge their changes into their team's "main" environment - much like how git works.

However, this has its limitations - and a very big one at that too in my opinion. It does not keep track of the steps that a user took in their environment individually. It only takes care of the final result.

I had a lambda function that was being used in an AWS Appsync pipeline. As the needs of the project changed, I determined that this function's name no longer matches the task that it carries out. I wanted to rename the function. This requires one to delete the original function and create a new one with the new name - as there is no command that amplify provides to rename a function. Fair enough. However, this isn't the main problem. You see - since the function was used in an appsync pipeline (a custom resolver at that too - and not just a @function directive) - I had to:

• first remove the reference to the old function name from the pipeline
• remove the old function
• create the new function with the new name
• add the new named function back to the pipeline

or so I thought. Turns out, I had to not just carry the above out, I had to carry them out individually - wherein I had to:

• carry out one task
• commit the changes
• move the changes into the main environment
• and repeat the above steps again for the next task.

See the problem here - I could not carry out all four tasks and then commit the changes - and have them merged with the main environment. I had to repeat the commit and the move-to-the-main-environment tasks for each individual task I had!

Why so? It turns out amplify would do things out of order (or perhaps it would do them in parallel instead of in series). It would remove the old function first, then update the pipeline with the new function name - and would then throw an error because the new function had not yet been created!! Had it tracked the order in which the individual steps were performed and then proceeded to adhere to this order when updating the main environment, we would not have to go through the effort of repeating the tasks again and again for each individual step.

With databases, when one modifies it, they would create migrations to keep track of the order in which the modifications are introduced. When a new instance of the database is created or has to be updated, it follows the migration order precisely to avoid the issue we currently face above.

But this "migration" feature is missing in Amplify. As a consequence, a task that could take a couple of minutes when using the AWS console or CLI now could take couple of hours, as you wait on your team to merge the changes of each individual task before you can proceed with the next task - only because amplify's design is flawed and does not really cater to "teams" as it would like you to believe.