First Time ExperienceMay 31, 2020

AWS Amplify

I was able to easily spin up a sample project, with a DynamoDB and GraphQL backend, play around with it, make changes, with very little friction. If I would’ve stopped at the introductory tutorial, I think my review would be a little different.

with Rick Blalock

I read through the different features in the marketing materials and then jumped to the introduction documentation and it really got me excited. “Man! I can do all this, this easily?! I have to try to port some of Fish Rules to this”, was what I thought.

Getting started tutorial does a good job telling you why and what is going on during the setup of a new project and it does it in as few as words as possible, which is great. I was able to easily spin up a sample project, with a DynamoDB and GraphQL backend, play around with it, make changes, with very little friction. If I would’ve stopped at the introductory tutorial, I think my review would be a little different.

About the tester

For context, here’s the related experience (or lack thereof) I have with the product and the ecosystem(s) it touches:

  • I’ve never personally used Amplify
  • I’ve had some customers that used it and we’ve talked through certain things Amplify was to be used for, how they were going to architect their app, etc. I helped them with specific things related to their application written in NodeJS and in GraphQL but did not help with the specifics of Amplify
  • I’m familiar with the concepts of Amplify, with GraphQL, with AWS, etc.
  • I’ve followed the community around Amplify for some time
  • Prior to the friction log, I sped read through the docs, the concepts, marketing material, value-adds, etc.

Logs 10


Setup - init

This is technically friction and a delight. When setting up a project via amplify init, it sets up the cloud formation, IAM, s3 bucket roles, etc. On the one hand, this is really great and much better compared to how other parts of AWS do things. On the other hand, because it’s the AWS ecosystem, I see all the things set up behind the scenes and it causes a little bit of anxiety because I’m unsure what it all does initially, how will I manage those different pieces, etc.


Setup - amplify configure

When running amplify configure it took me to the AWS console to continue configuration. On one hand, it was nice to redirect to the right spot right away, which I much better than explaining where to go in a series of steps. The small amount of friction was I wasn’t sure which console it took me too (I have a lot of different AWS accounts). This really isn’t an Amplify problem but an age-old AWS console problem where it’s never really clear what org or console instance you’re logged in to without a click or two. I had to swap out to another org to continue.


Typescript in starter tutorial

Could not find a declaration file for module './aws-exports'

When I setup the project, I created a React + Typescript project (I used Snowpack v2). The type definitions of the aws-export file were missing so I needed to add a generic one. The simple fix was to add the following to the TS definition file:

declare const awsmobile: {};
export default awsmobile;

And in the TS config file: "allowJs": true


GraphQL Relay Spec Difference

I’ve used GraphQL in a lot of different settings and from different vendors (GraphCMS, Apollo, our own personal setup at Pinpoint, etc.). In every case, the Relay spec was used. When generating a GraphQL schema and model in Amplify, the DSL of the graph is different than the Relay-like spec that I'm familiar with (plural/singular names, edges → nodes, etc). This is not a huge deal but it did cause me to pause and wonder if this was consistent across other parts of this product or something I had done in the setup.


Some language and terms feel overloaded

There's some cognitive overhead and language friction with some of the features, products, terms strewn together. e.g. an “AppSync GraphQL API Lambda Function"


Adding a custom resolver

Adding a custom resolver is intimidating because of all the boilerplate & config code, reference: a custom resolver that resolves a DynamoDB table. It's not immediately clear why a stacks/ definition has to be there, to create a resolver. It’s not clear even what it does without diving in to a bunch of other content that isn't accessible from this page.

"Write the resolver template" is a step. What is that? What is it for? Is it a file that needs to be created? etc.

"Velocity is useful as a fast..." what is that? Where do i find out more about this? Who created and maintains Velocity? Also the snippet has no code highlighting so it gave me the feeling its a random text file that can’t be tested against, or ran as code in my editor, etc.

"Add the function as an AppSync data source in the stack’s Resources block." . It'd be nice if add function did this for you. The same goes for the ”Create an AWS IAM role” part of the instructions.


Using another datasource

Setting up DynamoDB with the starter tutorial was mostly frictionless. It’d be nice if the same worked with Aurora (or other data sources). There’s a lot more you have to do to setup MySQL, for example.


Deleting an Amplify project

I went to clean up my project and got lost in the UI at some point (I still wasn’t up to speed on the difference between a “project” and an “API”). So I deleted the API part of what I created and all the resources from s3, to DynamoDB tables were still there. I went through and manually deleted all those and stumbled on the “project” in Amplify and deleted that. I assume that would’ve cleaned up the other resources but didn’t have a way to try it out after the fact.


Exponential complexity

Regarding a UX principle, "Principle of Least Astonishment" (POLA), the biggest surprise this experience gave me was how it went from the feeling of things being super easy to the weight of a really complex set of configurations. From "Oh I ran a few commands and I have an app with a DB and an API" to, "I have to do all of this just to create a hello world function?" It's a pretty stark experience going from one side of the getting start tutorial to doing something practical with it.


Porting an existing application

After I finished the getting started tutorial, I got lost on where to go next or what to learn and tackle next. I had several use cases from an existing app, which included porting some logic from a Node app and from a few Firebase functions.

I read up on creating custom resolvers, how people run Node apps on Amplify, and a few other internet related articles. After generating a function and seeing all the files and configuration and seemingly endless things to try to figure out just to run a "hello world" resolver, it really discouraged me from continuing further. Some reasons for this from an emotional standpoint:

(1) It's not clear what all the config does or is for and copy/pasting it seemed worrisome

(2) It's not this complicated in products I was looking at to port this app to. This caused me to go through the emotions of "maybe I don’t need to do this”, “What other platforms could I use” and "Man what is maintaining this like".

Sign up for updates

Friction Log © 2020.