Hi guys and welcome to another edition of CDS’ blog. Today we are going to do a quick walkthrough of one of the services offered by AWS: Amplify.

First of all, in case you aren’t up to speed we need to introduce AWS or Amazon Web Services. It's a cloud of services offered by Amazon created with the idea of helping people to build apps and websites by solving different needs that a project may have: from basic things like hosting and databases to more complex stuff such as IoT, AR, and a bunch of other advanced web services. As of 2022, AWS offers more than 200 services! That’s a lot and it can get rather complex to know what services you should or shouldn’t use.

With that in mind, AWS created Amplify - Amazon defines it as “a set of products and tools that enables mobile and front-end web developers to build and deploy secure, scalable full-stack applications, powered by AWS.”. Basically, it’s another service exposed by AWS that helps you to orchestrate and maintain your application through a set of tools (CLI and clients).

To achieve that, Amplify supports itself in the serverless approach to divide an application into a set of components each with one focus in mind. Each of these components is based on one or a set of other services, the most relevant ones being: 

  • Auth
  • Functions
  • Storage
  • API
  • Analytics and notifications

Auth - AWS Cognito / AWS IAM

This resource encapsulates the creation, authentications, and authorization of users based on a bunch of different configurations that are available. Within these configurations the following flows are supported:

  • 2FA based on an SMS
  • Social sign in with Google or Facebook as trust providers
  • Forgot password
  • Password composition customization
  • Whitelisting of devices
  • And a bunch more

Besides offering these, Cognito also has a customizable authentication and authorization flow that can be defined and altered using something called Lambda Functions. This allows your app or site to have as many steps and confirmations in its different flows as it likes.

All these features are oriented to registering and maintaining users, but how does Amplify handle the interactions with other APIs or non-human collaborators or consumers of data? Amplify also supports having mixed authorization methods with API keys generated and kept safe within the cloud of AWS. 

Functions (computing) - AWS Lambda

Think of this service as chunks of code that can be defined and run in a bunch of different places to meet your needs. In our previous resource, we talked about defining your own custom authentication or authorization flows, but this service can be “hooked” to a bunch of other different flows. From creating a thumbnail for an image after it gets uploaded, to processing and storing the video in a bunch of different qualities to later stream, or defining the business logic of your app or web page.

Besides having the possibility of creating a bunch of functions and running them, AWS Lambda also offers a tool with which you can encapsulate and reuse the dependencies of your functions and reuse them in an elegant manner. This is called layers and it helps to maintain a clean and reusable codebase.

Storage - S3/DynamoDB

This resource encapsulates the need for storing data for later consumption. This can be information to later display or static assets that can be later fetched and displayed or used.

In the first case, we would be referring to DynamoDB - this is a document database (similar to Mongo or Firestore) created with a bunch of restrictions with the sole intention of always being able to respond in the quickest way possible. DynamoDB stores data based on tables that need to have a schema defined through the CLI, as well as some definitions that need to be done to know what identifies a record from each other and some other optimization configurations.

For the second case, we would be referring to S3, which is a widely used and known service that handles the storing and fetching of static files (images, videos, plain text files, pdf reports, etc.). With a correct configuration between the Auth and the Storage bucket, we can have a set of scopes defined in a way in which some of the files in the bucket are public and some are private.

API - AppSync/API Gateway

With this resource, we are able to expose behavior to the world for consumption. This can be achieved using one of two types of APIs: GraphQL (relying on AppSync) or REST (relying on API Gateway).

The first option exposes a model with a defined set of operations (Mutations, Queries, and Subscriptions) as well as a set of resources to be consumed by the client. All of this is done following a definition made by the dev in a file called schema.graphql that gets generated when we add this resource. Besides handling the exposition of our GraphQL API, AppSync also creates and maintains on its own a set of tables based on the definition of the model that we specified. Amplify also provides a set of directives used to make our lives as dev easier. We will go into them in our next article, so stay tuned!

The second option exposes an endpoint as an entry point to our REST API and we can define whatever resources we want within that route, for each of them we are going to have to define a chunk of code to handle what should happen when that resource is called. Additionally, if needed, we are going to have to define a DynamoDB Table to set the data and keep that updated on our own.

Analytics & Notifications - AWS Pinpoint

This is basically another service to handle the registering of events and later analyzing the data that gets generated, as usual, you can use that to determine which flows in your app or website are losing users and improve them. 

Additionally, you can also use this service to send a variety of notifications to your users:

  •  push notifications
  • Apple Push Notification Service
  • Google Cloud Messaging
  • SMS’s
  • Email’s based on templates

Pros and cons

This can’t be a post in tech without comparing the + and - of using this specific technology, so here we go:

  • It’s a generic tool that can be used in multiple scenarios
  • Setting a backend can be done really quickly
  • The directives have some entry costs but can be very helpful
  • Default operations save a bunch of time
  • Integrated CI/CD for BE and FE
  • As it only has a document DB, complex relational solutions aren’t really its thing
  • Not all operations are customizable (Subscriptions)
  • You might end up not using the default operations for a model
  • The default operations use query instead of scan; they may end up doing a bunch of requests for nothing

Stay tuned for part 2 of the article to learn more about the directives that will save you lots of time when setting up an API.