DEV Community: Evertson Croes

Processing long running events on AWS API Gateway

Evertson Croes — Fri, 17 Apr 2026 08:19:51 +0000

Processing long running events on AWS API Gateway

AWS API Gateway is a managed HTTP/REST service provided by AWS. It provides a relatively simple way to host an API and offers rich functionality when it comes to customizability, security and integration. AWS API Gateway enforces a maximum integration timeout of 29 seconds. For most APIs this is perfectly reasonable.

However, problems arise when an API must trigger operations that take minutes to complete, such as generating large exports or running complex background jobs. In our case, we needed to generate large database exports that could take several minutes. A synchronous API request was therefore not an option. One example is the generation of large exports from a database. This became a challenge with the default setup we had with API Gateway.

AWS provides some guidance on this in their documentation. However, in this blog article I want to share how we solved this problem in our project in more detail and also provide a working CDK project as an example.

The problem

As mentioned in the intro, we have a time limit of 29 seconds on requests on API Gateway. But the problem is also that we want to run functionality that could potentially run for many minutes. In this case, we do not want to run a synchronous call, but an asynchronous call. Meaning that even if API Gateway would allow us to keep a request open for 30 minutes, it would not be beneficial for a frontend application to keep one blocking request open for that long since it takes up resources.

So we also need a mechanism to handle asynchronous requests while still using API Gateway.

The TaskManager

We ended up calling the solution to this problem the “TaskManager”. It can be seen as one Microservice with the sole responsibility of keeping track of tasks. It does not actually process the tasks. The following diagram provides a high-level overview:

In this overview, there are Task Suppliers, Task Processors and the TaskManager itself. It is important to note that in our use cases, we have not yet found a scenario where there are multiple suppliers of the same task and multiple processors for the same type of task. However, the pattern introduced in this blog could be expanded to include this if necessary.

If we zoom in to the TaskManager, we have the following components:

(Click here to see diagram better)

This diagram depicts the deployment and the flow at the same time. On the left side, we can see a Task Supplier. For this example, it does not matter what this is. It could be any component that can do a HTTP request. In our example, it was a Backend-for-Frontend API Gateway.

This Task Supplier calls one of the two endpoints available in the TaskManager API, which itself is an API Gateway, that allows the creation of a Task via a HTTP POST request. This triggers a Lambda function that will create the task in the TaskStatus DynamoDB Table.

When an entry is created in this Table, a DynamoDB Stream will trigger the TaskStatusPublisher Lambda. This Lambda will check if this is a new entry (indicated by the INSERT) and in this case will publish a “TaskCreatedEvent”. It is important to note that this event also contains the Task Type. This is important as the type determines which processor needs to process it.

This is essentially where the first flow of the TaskManager ends. It is the responsibility of the Task Processor to create an EventBridge rule to consume this event and process the event.

The TaskManager expects to be regularly updated by the TaskProcessor via the TaskUpdatedEvent. The status of the event can be updated to RUNNING, SUCCESSFUL and FAILED. In the case of SUCCESSFUL, a payload can also be added. This could be the result of the task or in our case for the large exports, a signed S3 bucket URL to download it.

The Task Supplier can poll for the task regularly and get the status. Based on this status it can decide how to react.

Notice that the TaskStatusPublisher also publishes TaskRunningEvent, TaskSuccessfulEvent and TaskFailedEvent. This could be used in combination with a WebSocket mechanism to receive live updates instead of polling. However, this is out-of-scope for this blog.

This setup benefits from being completely serverless, meaning we can scale up on higher loads but also scale down to zero if there are no tasks. For this reason, in our case, we have only created one instance of this TaskManager that is shared by all tasks in our system. However, you could create multiple TaskManagers for different bounded contexts or even for each type of task.

CDK Project

The example CDK project of this setup can be found in this GitHub repository. There is a README file which explains how to build and deploy the project to your own AWS environment.

Final Thoughts

This pattern is a simple but powerful way to:

Work around API Gateway limitations
Build scalable async workflows
Keep your frontend responsive

If you're dealing with long-running operations in AWS, this approach is definitely worth considering.

The Amplify Series, Part 7: Track app usage with Amplify Analytics

Evertson Croes — Sun, 18 Jun 2023 17:25:05 +0000

In the previous part of this series, we added the Amplify Predictions category, which allowed us to use the power of AI and Machine learning to identify text in images, convert text to speech and interpret sentiment of the text. In this part of the blog series, we will add functionality to be able to track the usage of our application in order to learn how our users use the application and be able to improve the application user experience based on this information. We will do this by adding the Amplify category called Amplify Analytics.

We will start by adding this category to the project. We will create a new page for the Amplify Analytics category and add some interactable elements to that page so that we can track the usage of these elements. We will also be updating the previous pages when needed in order to track the usage of those pages. In the end, you will have a better understanding of this category and be able to track the usage of your Amplify application.

We will continue in the repository where we left off in the previous blog post.

Adding the Analytics category

We will start by generating the backend resources needed for the tracking functionality.

We will run amplify add analytics with the following options:

Analytics provider: Amazon Pinpoint
Resource name: <>
Unauthenticated users: No

? Select an Analytics provider Amazon Pinpoint
✔ Provide your pinpoint resource name: · theamplifyapp
⚠️ Auth configuration is required to allow unauthenticated users, but it is not configured properly.
⚠️ Adding analytics would add the Auth category to the project if not already added.
? Apps need authorization to send analytics events. Do you want to allow guests and unauthenticated users to send analytics events? (we recommend you a
llow this when getting started) No
⚠️ Authorize only authenticated users to send analytics events. Use "amplify update auth" to modify this behavior.
✅ Successfully updated auth resource locally.
✅ Successfully added resource theamplifyapp locally

This command will add a new directory called analytics to our amplify/backend directory, which will contain information needed to create the resources in AWS to support the new functionality.

We will run amplify push to create these resources in AWS. The AWS service used here is Amazon Pinpoint.

Note that using this service will cost you money. The first 100 million events recorded per month are free. After that, you pay $0.000001 per event you collect. A piece of general advice: configure a budget with billing alerts for your AWS account so you don’t get surprised by high costs.

After running the amplify push command you will not be charged since the application must be configured to send events to AWS Pinpoint. Once we configure this, however, the application will automatically start sending a minimal set of events such as page visits. This can be turned off and will be covered in the next section.

Once we have created the resources, we can run amplify console analytics to open the Amazon Pinpoint console. Initially, all charts should be empty:

In the next step, we will configure the frontend application to start sending data to Amazon Pinpoint to fill these graphs.

Configuring the frontend for Analytics

To start, we will update our main.ts to include the following:

import { Predictions, Analytics } from 'aws-amplify';

By simply importing this dependency,running the application again and visiting it in the browser, we can see that the charts are being updated:

We can also click on the demographics to see information about the users:

With this small addition to the frontend application, we can now see how much the application is being used and from what type of devices. If you want to have more information about the users of the application, it is possible to customize the information sent about a user. We will not cover that part in this blog, however, a complete example can be found on this page.

Session tracking

The session metric in AWS Pinpoint provides information about how often your application has been opened. However, once a session is registered for a device (mobile, browser, etc.) the session counter does not go up if the same device visits the site again within a certain time period. Refreshing the page or closing the browser and opening it again is not a new session. This is because the Amplify SDK creates a unique identifier for your device.

After the page has not been active on the device for some time or if your application manually calls Analytics.stopSession the session will terminate. Opening the page again after this will register as a new session.

The session is tracked by default, however, you can turn it off by adding the following code in the main.ts:

Analytics.autoTrack('session', {
    enable: false
});

Page view tracking

We can also configure the application to track which pages are visited. We will update the main.ts with the following:

Analytics.autoTrack('pageView', {
  enable: true,
  type: 'SPA',
  attributes: {
    url: window.location.origin + window.location.pathname
  },
})

Now you can run your application and visit some of the pages. If you visit the events page in AWS Pinpoint you can see how much each page is viewed:

Disclaimer: It can take up to 30 minutes for the events to show up in Pinpoint.

Recording events

We can record events such as clicks on the pages with Amplify Analytics. This section describes two ways to do that.

Manual event recording

The first way is to do it manually. We will update our text-to-speech.component.ts to send an event to AWS Pinpoint every time the user uses the text-to-speech functionality. The event will contain the text that the user entered:

// Other imports
import { Predictions, Analytics } from 'aws-amplify';  // <--- Add import

@Component({
  selector: 'app-text-to-speech',
  templateUrl: './text-to-speech.component.html',
  styleUrls: ['./text-to-speech.component.css']
})
export class TextToSpeechComponent implements OnInit {
  // Other existing code

  convertToAudio = async () => {
    if (!this.textInput) {
      return;
    }

    // Add this 
    Analytics.record({
      name: 'convertedTextToSpeech',
      attributes: { textInput: this.textInput },
      immediate: true
    });

    // Other existing code
  };

  // Other existing code
}

This will now show up in our events every time a user uses this functionality:

In a real application, you might not want to set an attribute value as we did here for an input field. Since the users of the application are free to enter any value they want, the attribute value list in the filters will explode. However, this example gives an impression of what is possible with the minimal setup we have so far.

Automatic event recording

The other way to record events is to set up an event tracker that will activate when an element contains certain properties. We will update the main.ts to include the following:

Analytics.autoTrack('event', {
  enable: true,
  events: ['click'],
  selectorPrefix: 'data-amplify-analytics-'
});

This will track all click events for HTML elements that have properties with the prefix data-amplify-analytics-.

We will now update our comments.component.html to make use of this so that an event is sent to AWS Pinpoint every time someone adds a comment to the post.

    <!-- Other existing code -->

    <div class="col-lg-4">
      <button
        class="aws-button"
        data-amplify-analytics-on="click"
        data-amplify-analytics-name="commentAdded"
        (click)="addComment()"
      >
        Add Comment
      </button>
    </div>
  <!-- Other existing code -->

This event will also show up similar to the previous one in our events dashboard:

We now have enough tools to be able to track the usage in our application.

The following code changes have been made to our repository in this article:

Amplify Analytics vs Google Analytics

When deciding to track app usage, you can also use Google Analytics, which is unarguably more feature-rich and streamlined than Amplify Analytics.

Amplify Analytics uses AWS Pinpoint, which has analytics capabilities but is more focused on user interaction, such as sending emails and notifications for campaigns.

Google Analytics is the industry standard when it comes to Analytics as it provides many features and is very user-friendly compared to AWS Pinpoint in my opinion. So how do you choose between the two?

My advice would be to choose AWS Pinpoint if you want to get a quick view of the usage of your application. If you already have an Amplify application, you can get up and running with analytics with just a few changes to your application as we have seen in this blog post.

If you want to go further than seeing the general usage, event usage, and demographics, then you should consider using Google Analytics, especially if you or someone on your team already has experience with it.

Up next: Location functionality with Amplify Geo

In this blog we have used Amplify Analytics to track the app usage of our application. As with the previous categories, there is more that you can do with this category than what is covered in this article, so be sure to check the documentation for more information. In the next article, we will take a look at how to use Amplify Geo to add location-based functionality.

The Amplify Series, Part 6: Using the power of AI and Machine Learning with Amplify Predictions

Evertson Croes — Thu, 23 Mar 2023 14:38:29 +0000

In the last part of this series, we added the Amplify Storage category, which allowed us to retrieve and upload files to S3 directly from our application. In this part of the blog series, we will add even more functionality, such as identifying text from an image, converting text to speech, and interpreting the sentiment of text. We will do this by adding a new Amplify category called Amplify Predictions which will allow us to use the power of AI and machine learning to access powerful functionality out of the box.

As usual, we will start by adding the category to the project. We will then create a new page for the Amplify Predictions category and add sections to that page per functionality available. This page will serve as a showcase for all the possibilities within Amplify Predictions. In the end, you will have a better understanding of this category and be able to appreciate how easy it is to get this functionality working in your applications.

Amplify app repository update

We will continue in the repository where we left off in the last blog post.

There have been 2 extra commits to this repository since the last blog post. These are:

Now we are ready to get started and add more functionality to our application.

Identify text from uploaded image

In this section, we will add functionality that will allow us to upload an image and retrieve the identified text inside the image.

Generating the backend resources

We will run amplify add predictions with the following options:

Category: identify
What would you like to identify: Identify Text
Friendly name: <>
Identify documents: yes
Access: Auth users only

The Amplify CLI output will look similar to this:

Evertsons-MacBook-Pro:theamplifyapp evertsoncroes$ amplify add predictions
✔ Please select from one of the categories below · Identify
✔ What would you like to identify? · Identify Text
✔ Provide a friendly name for your resource · identifyTextd230b04a
✔ Would you also like to identify documents? (y/N) · yes
✔ Who should have access? · Auth users only
Successfully added resource identifyTextd230b04a locally

As with the previous category, we want only to allow access to authenticated users. This command will add a new directory called predictions to our amplify/backend directory, which will contain information needed to create the resources in AWS to support the new functionality.

Bug: Before continuing, we need to add some manual changes to the generated output since there is a bug in the 10.8.1 version of the Amplify CLI. To fix the issue, open the amplify/backend/predictions/identifyText<<id>>/parameters.json file and add the following three key-value pairs to it:

"format": "PLAIN"
"access": "auth"
"identifyDoc": "document"

We will run amplify push to create these resources in AWS. The AWS services used here are Amazon Rekognition for image recognition and Amazon Textract for document analysis.

Note that using these services will cost money. Amazon Rekognition will cost around $0.001 per image processed, while Amazon Textract costs around $0.0015 per document processed. As a general rule, be sure to set up a budget with billing alerts for your AWS account so you don’t get surprised by large costs.

These commands will add the following changes to our repository.

Adding the predictions page

The first thing we need to do is add a new component to our frontend application that will contain all the predictions functionality:

ng generate component components/categories/predictions

This will generate the expected files for our component. We will then link up routing to be able to render this component. Refer to this commit for the details so far.

Adding Text identification functionality to the Predictions page

We will add a new frontend component that will contain the functionality to upload an image and identify the text in that image:

ng generate component components/categories/predictions/identify-text

Inside our predictions.component.html we must make sure to add the newly generated identify-text component:

<app-identify-text></app-identify-text>

Inside the identify-text.component.html, we will add:

<input
  type="file"
  id="imageUpload"
  name="imageUpload"
  accept="image/png, image/jpeg"
  (change)="imageSelected($event)"
/>

Similar to the last blog, this will give us an input that we can use to select images from our device. We have to add logic to react to the image that is selected in our identify-text.component.ts:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-identify-text',
  templateUrl: './identify-text.component.html',
  styleUrls: ['./identify-text.component.css']
})
export class IdentifyTextComponent implements OnInit {
  selectedFile: File | undefined = undefined;

  constructor() {}

  ngOnInit(): void {}

  imageSelected = (e: Event) => {
    const input = e.target as HTMLInputElement;

    if (!input.files?.length) {
      return;
    }

    this.selectedFile = input.files[0];
  };
}

We will now be able to select a file and it will be stored in the selectedFile variable. Normally it would be best practice to add this logic to a separate component so that we can reuse this code. However, to keep the blog shorter we will allow duplicate code.

Now that we have the functionality to upload an image, we need to add a button that does something with the selected image. We will also show the identified text and also add some CSS to identify-text.component.html:

<div class="container-fluid card-background">
  <h2>Identify Text</h2>
  <input
    type="file"
    id="imageUpload"
    name="imageUpload"
    accept="image/png, image/jpeg"
    (change)="imageSelected($event)"
  />

  <button class="aws-button" (click)="identifyText()">
    Identify Text
  </button>
  <div class="identified-text" *ngIf="identifiedText">
    Identified words:
    <div *ngFor="let word of identifiedText.text.words">
      {{ word.text }}
    </div>
  </div>
</div>

Once this button is clicked, the identifyText function is called. We will define this function in the following way in our identify-text.component.ts:

import { Component, OnInit } from '@angular/core';
import { Predictions } from 'aws-amplify'; // <---NEW
import { IdentifyTextOutput } from '@aws-amplify/predictions'; // <---NEW

@Component({
  selector: 'app-identify-text',
  templateUrl: './identify-text.component.html',
  styleUrls: ['./identify-text.component.css']
})
export class IdentifyTextComponent implements OnInit {
  selectedFile: File | undefined = undefined; // <---NEW
  identifiedText: IdentifyTextOutput | undefined = undefined; // <---NEW constructor() {} ngOnInit(): void {} identifyText = async () => {
    if (!this.selectedFile) {
      return;
    }

    //ADD THIS FUNCTION
    Predictions.identify(
      {
        text: {
          source: {
            file: this.selectedFile
          }
        }
      },
      {}
    )
      .then(response => (this.identifiedText = response))
      .catch(err => console.log({ err }));
  };

  //OTHER CODE
}

In these changes we import some components we need related to Amplify Predictions. We add two properties to our components, the selectedFile which will hold the latest uploaded image and the identifiedText which will hold the latest results of identified text we received from AWS. We will then call the identify function with the selected image to be sent to AWS. The response will be set to the identifiedText field and the words will show up on the screen.

There is one more step we need to take. The Predictions component needs to be supplied with a Provider. This can be done in the main.ts file:

#other imports

import { Predictions } from 'aws-amplify';
import { AmazonAIPredictionsProvider } from '@aws-amplify/predictions';
Amplify.configure(aws_exports);
Predictions.addPluggable(new AmazonAIPredictionsProvider());

#other code

Once this is all done, we can run our application, upload an image, identify the text and see the results on the screen. When I used this image:

I got the following result:

There are more options to play around with, including identifying entities and labels in images and many ways to finetune the results. For more information on this, checkout the Amplify Predictions documentation.

The changes for this section can be found in this commit, including the changes needed for the CSS.

Convert text to speech

In this section we are going to add functionality to convert text to speech using Amplify Predictions.

Generating the backend resources

We will first generate the backend resources needed. We will run amplify add predictions with the following options:

Category: Convert
What to convert: Generate speech audio from text
Friendly name: <>
Source language: US English
Speaker: Kevin – Male
Access: Auth users only

The Amplify CLI output will look similar to this:

Evertsons-MacBook-Pro:theamplifyapp evertsoncroes$ amplify add predictions
✔ Please select from one of the categories below · Convert
✔ What would you like to convert? · Generate speech audio from text
✔ Provide a friendly name for your resource · speechGenerator11c4cfca
? What is the source language? ...  (Use arrow keys or type to filter)
✔ What is the source language? · US English
✔ Select a speaker · Kevin - Male
✔ Who should have access? · Auth users only
Successfully added resource speechGenerator11c4cfca locally

This is very similar to what we previously did for the text identification. We can run amplify push again to create the resources in AWS. The AWS service that will be used for this functionality is Amazon Polly. The costs for using Amazon Polly is around $4.00 per 1 million characters.

These commands will add the following changes to our repository.

Adding text-to-speech functionality to the Predictions page

Similar as we did for the text-identification, we will add a component that will handle all of the text-to-speech functionality:

ng generate component components/categories/predictions/text-to-speech

Inside our predictions.component.html we will make sure to add the newly generated text-to-speech component:

<app-text-to-speech></app-text-to-speech>

Inside the text-to-speech.component.html, we will add a text input and a button to play the text:

<div class="container-fluid card-background">
  <h2>Text to speech</h2>
  <input
    type="text"
    id="textInput"
    name="textInput"
    (change)="textInputUpdated($event)"
  />

  <button class="aws-button" (click)="convertToAudio()">
    Play
  </button>
</div>

Now we need to hook up these elements to our text-to-speech.component.ts and call the Predictions component to do the conversion from text to an audio buffer for us. Finally, we play the audio:

import { Component, OnInit } from '@angular/core';
import { Predictions } from 'aws-amplify';
import { TextToSpeechOutput } from '@aws-amplify/predictions';

@Component({
  selector: 'app-text-to-speech',
  templateUrl: './text-to-speech.component.html',
  styleUrls: ['./text-to-speech.component.css']
})
export class TextToSpeechComponent implements OnInit {
  textInput: string | undefined = undefined;

  constructor() {}

  ngOnInit(): void {}

  convertToAudio = async () => {
    if (!this.textInput) {
      return;
    }

    Predictions.convert({
      textToSpeech: {
        source: {
          text: this.textInput
        },
        voiceId: 'Amy'
      }
    })
      .then(async result => {
        this.playAudio(result);
      })
      .catch(err => console.log({ err }));
  };

  playAudio = async (audio: TextToSpeechOutput) => {
    const context = new AudioContext();
    const buffer = await context.decodeAudioData(audio.audioStream);
    const source = context.createBufferSource();
    source.buffer = buffer;
    source.connect(context.destination);
    source.start();
  };

  textInputUpdated = (e: Event) => {
    const input = e.target as HTMLInputElement;
    this.textInput = input.value;
  };
}

Bug: There is currently, at the time of writing, a bug in Amplify that does not allow us to use the voiceId “Kevin”, which we selected when creating the backend resources. Selecting the voiceId “Amy” works, so we will use that.

In the code snippet above we create a field that will hold the text in the textInput. We have a method that is called to convert the text to audio using the Predictions component. The convert function will send an http request to Amazon Polly and an audioBuffer will be returned. This can be given to an AudioContext component to play to audio in the browser.

The changes made in these steps can be found in this commit.

Interpret the sentiment of text

The final set of functionality we are going to add is the ability to interpret the sentiment of text.

Generating the backend resources

We will add the backend resources by again running amplify add predictions with the following options:

Category: Interpret
Friendly name: <>
Kind of interpretation: ALL
Access: Auth users only

The Amplify CLI output will look similar to this:

Evertsons-MacBook-Pro:theamplifyapp evertsoncroes$ amplify add predictions
✔ Please select from one of the categories below · Interpret
Only one option for [What would you like to interpret?]. Selecting [Interpret Text].
✔ Provide a friendly name for your resource · interpretText9001208a
✔ What kind of interpretation would you like? · All
✔ Who should have access? · Auth users only
Successfully added resource interpretText9001208a locally

And now we can run amplify push to create the resources in AWS. The AWS service that will be used for this functionality is Amazon Comprehend. The pricing for this service can be found here.

These commands will add the following changes to our repository.

Adding text-interpret functionality to the Predictions page

We will first create a component that will handle the text-interpret functionality:

ng generate component components/categories/predictions/text-interpret

Inside our predictions.component.html we will make sure to add the newly generated text-interpret component:

<app-text-interpret></app-text-interpret>

Inside the text-interpret.component.html, we will add a text area input and a button to trigger the interpretation of the text and a text to show what the sentiment is:

<div class="container-fluid card-background">
    <h2>Interpret text</h2>
    <textarea
        id="textAreaInput"
        name="textAreaInput"
        rows="5"
        cols="66"
        (change)="textInputUpdated($event)"
    ></textarea>

    <button class="aws-button interpret-button" (click)="interpretText()">
        Interpret
    </button>
    <div *ngIf="interpretation">
        Interpretation = {{ interpretation.textInterpretation.sentiment?.predominant }}
    </div>
</div>

Now we will update the text-interpret.component.ts to hook up the functions defined here and call the Predictions component to interpret the text:

import { Component, OnInit } from '@angular/core';
import { Predictions } from 'aws-amplify';
import { InterpretTextCategories, InterpretTextOutput } from '@aws-amplify/predictions';

@Component({
  selector: 'app-text-interpret',
  templateUrl: './text-interpret.component.html',
  styleUrls: ['./text-interpret.component.css']
})
export class TextInterpretComponent implements OnInit {
  textInput: string | undefined = undefined;
  interpretation: InterpretTextOutput | undefined = undefined;
  constructor() { }

  ngOnInit(): void {
  }

  interpretText = async () => {
    if (!this.textInput) {
      return;
    }

    Predictions.interpret({
      text: {
        source: {
          text: this.textInput
        },
        type: InterpretTextCategories.ALL
      }
    }).then(result => this.interpretation= result)
    .catch(err => console.log({err}))
  }


  textInputUpdated = (e: Event) => {
    const input = e.target as HTMLInputElement;
    this.textInput = input.value;
  };
}

We can now try our entering text in our text area and doing a sentiment check. I Googled “happy poems” and entered the first one I found:

Try adding different types of text to check the interpretation. Furthermore, the response to the interpret function also contains more information related to the interpretation of the text. Check the documentation for more information and possibilities.

The changes made in these steps can be found in this commit.

Up next: Tracking app usage with Amplify Analytics

In this blog we have used Amplify Predictions to identify text in images, convert text to speech and interpret the sentiment of text. There are more possibilities in this category, however, these examples should give you an idea. In the next article, we will look at using Amplify Analytics to collect analytics data for your application.

The Amplify Series, Part 5: Uploading and retrieving images with Amplify Storage

Evertson Croes — Sun, 19 Feb 2023 19:38:17 +0000

With our application in place, it is now time to start adding more functionality using some of the other Amplify categories. In this article, we will be adding Amplify Storage to upload and retrieve images from AWS in just a few steps.

We will start off by adding the Amplify Storage category to our project. We will follow up by using the Storage component to be able to upload and list all of our images. Finally, we will create some UI that will make use of this functionality. At the end of this article, you will have a better understanding of Amplify Storage and can use it in any scenario regarding file uploads and retrieval.

Adding Amplify Storage to our project

We will continue in the repository where we left off in the last blog post. From this point, we will run amplify add storage with the following options:

Service: content.
Friendly name: amplifyappimages.
Bucket name: amplifyappimages
Access: create, update, read, and delete, for authorized users only.

The Amplify CLI output will look similar to this:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify add storage

? Select from one of the below mentioned services: Content (Images, audio, video, etc.)

✔ Provide a friendly name for your resource that will be used to label this category in the project: · amplifyappimages

✔ Provide bucket name: · amplifyappimages

✔ Who should have access: · Auth users only

✔ What kind of access do you want for Authenticated users? · create/update, read, delete

✔ Do you want to add a Lambda Trigger for your S3 Bucket? (y/N) · no

✅ Successfully added resource amplifyappimages locally

⚠️ If a user is part of a user pool group, run "amplify update storage" to enable IAM group policies for CRUD operations
✅ Some next steps:
"amplify push" builds all of your local backend resources and provisions them in the cloud

"amplify publish" builds all of your local backend and front-end resources (if you added hosting category) and provisions them in the cloud

We want users to be able to only see their own uploads. Therefore it is important that we select that only authenticated users can make use of this resource and that we give them all permissions so that they can upload, view and delete images. This is yet another useful example of how the Amplify Auth category automatically links with other categories to provide authentication and authorization functionality.

This command adds some changes to our repo. In the next step, we will start using the new category.

We will separate this functionality into three components:

Image uploader: A component responsible for uploading the image and giving the user feedback about the upload.
Image album: A component responsible for listing all uploaded images.
Image viewer: A component that will show only one image in a modal.

Adding an image overview page

We will first start by adding a new Angular component that will be used to show all images our users have uploaded:

ng generate component components/categories/storage

This will generate the expected files for our component. We will then link up routing to be able to render this component. This is all pretty standard Angular stuff that we have done in the previous blog, please refer to this commit for details.

Adding image upload functionality

We will now add a component that will contain the functionality to upload an image:

ng generate component components/categories/storage/image-upload

This will generate the expected Angular files. Inside our storage.component.html we will make sure to add the newly generated image-upload:

<app-image-upload></app-image-upload>

Inside the image-upload.component.html, we will add:

<input
  type="file"
  id="imageUpload"
  name="imageUpload"
  accept="image/png, image/jpeg"
  (change)="imageSelected($event)"
/>

This will give us an input that we can use to select images from our device. We have to add logic to react to whenever a user selects an image in our image-upload.component.ts:

import { Component, OnInit } from '@angular/core';

@Component({
  selector: 'app-image-upload',
  templateUrl: './image-upload.component.html',
  styleUrls: ['./image-upload.component.css']
})
export class ImageUploadComponent implements OnInit {
  selectedFile: File | undefined = undefined;

  constructor() {}

  ngOnInit(): void {}

  imageSelected = (e: Event) => {
    const input = e.target as HTMLInputElement;

    if (!input.files?.length) {
      return;
    }

    this.selectedFile = input.files[0];
  };
}

With this change we set the variable selectedFile to contain the contents of the file we selected. Now that we have this, we can add an upload button that uploads the selected image to the AWS cloud, which we previously configured.

We will start off by adding a button in image-upload.component.html:

<input
  type="file"
  id="imageUpload"
  name="imageUpload"
  accept="image/png, image/jpeg"
  (change)="imageSelected($event)"
/>

<button class="aws-button" (click)="uploadImage()"> <!---NEW!-->
  Upload
</button>

Once this button is clicked the uploadImage function is called. We will define this function in the following way in our image-upload.component.ts:

import { Component, OnInit } from '@angular/core';
import { Storage } from 'aws-amplify'; // <--- add this

@Component({
  selector: 'app-image-upload',
  templateUrl: './image-upload.component.html',
  styleUrls: ['./image-upload.component.css']
})
export class ImageUploadComponent implements OnInit {
  selectedFile: File | undefined = undefined;

  constructor() {}

  ngOnInit(): void {}

  //Add this function!
  uploadImage = async () => {
    if (!this.selectedFile) {
      return;
    }
    try {
      await Storage.put(this.selectedFile.name, this.selectedFile, {
        contentType: 'image/*',
        level: 'private'
      });
    } catch (error) {
      console.log('Error uploading file: ', error);
    }
  };

  //other code
}

We first import the Storage component from aws-amplify. We then define the uploadImage function that is used by our new button. This function uses the Amplify Storage component and calls the put method, which gets the file name, the file contents, and some properties.

In this case, the options include the type of file we want to accept and the authorization level. Setting the level to private means that only the user that uploaded this image will have access to it.

Once we have this in place we can select an image with our input and upload it using the new button. While we don’t see any feedback yet, if we go into our AWS console to S3 and search for our bucket, we should see that there is a new directory called “private” which contains a directory with the cognitoID of the user we used to upload the image. Inside this directory we can see the image that was uploaded:

Adding file upload progress feedback

In this step we want to show the user some feedback about the image upload process. We will start by adding an enum for the possible upload states and will set a variable in our component to have the correct state given the situation of the upload process. On our UI we will then show some text based on this state.

We will first make these changes to our image-upload.component.ts:

import { Component, OnInit } from '@angular/core';
import { Storage } from 'aws-amplify';

//Add this!
enum UploadState {
  IDLE,
  UPLOADING,
  UPLOAD_COMPLETE,
  ERROR
}

@Component({
  selector: 'app-image-upload',
  templateUrl: './image-upload.component.html',
  styleUrls: ['./image-upload.component.css']
})
export class ImageUploadComponent implements OnInit {
  selectedFile: File | undefined = undefined;
  //Add these 3:
  uploadStates = UploadState;
  uploadState: UploadState = UploadState.IDLE;
  progressText: string = '';

  constructor() {}

  ngOnInit(): void {}

  uploadImage = async () => {
    this.uploadState = UploadState.UPLOADING; // <--- Add this
    if (!this.selectedFile) {
      return;
    }
    try {
      await Storage.put(this.selectedFile.name, this.selectedFile, {
        contentType: 'image/*',
        level: 'private',
        progressCallback: this.progressCallback // <---- Add this
      });
      this.uploadState = UploadState.UPLOAD_COMPLETE; // <--- Add this
    } catch (error) {
      this.uploadState = UploadState.ERROR; // <---- Add this
      console.log('Error uploading file: ', error);
    }
  };

  //Add this function!
  progressCallback = (progress: any) => {
    this.progressText = `Uploaded: ${(progress.loaded / progress.total) *
      100} %`;
  };

  imageSelected = (e: Event) => {
    this.uploadState = UploadState.IDLE; // <---- Add this
    const input = e.target as HTMLInputElement;

    if (!input.files?.length) {
      return;
    }

    this.selectedFile = input.files[0];
  };
}

The upload state will start in IDLE, switch to UPLOADING and will either go into UPLOADING_COMPLETE or ERROR depending on how the call to Amplify Storage goes. The Storage.put function also allows for the definition of a progressCallback function in order to track the progress of the upload.

Once these are set in place, we add the following to our image-upload.component.html to be able to see the feedback:

<!---Existing code-->

<p
  *ngIf="
    uploadState === uploadStates.UPLOADING ||
    uploadState === uploadStates.UPLOAD_COMPLETE
  "
>
  {{ progressText }}
</p>
<p *ngIf="uploadState === uploadStates.UPLOAD_COMPLETE">
  Upload complete!
</p>

<p class="error-text" *ngIf="uploadState === uploadStates.ERROR">
  Something went wrong with the file upload
</p>

We will now get some feedback when uploading images.

The complete set of changes for this step can be found in this commit.

Adding an image overview

Now that we can upload images, we want to view all our uploaded images. We start by creating an image-album component:

ng generate component components/categories/storage/image-album

Now we are going to update the image-album.component.ts to contain logic to get all of the images for our user:

import { Component, OnInit } from '@angular/core';
import { Storage } from 'aws-amplify';

export interface Image {
  key: string;
  url: string;
}

@Component({
  selector: 'app-image-album',
  templateUrl: './image-album.component.html',
  styleUrls: ['./image-album.component.css']
})
export class ImageAlbumComponent implements OnInit {
  images: Image[] = [];

  constructor() {}

  ngOnInit(): void {
    this.getAllImages();
  }

  getAllImages = () => {
    Storage.list('', { level: 'private' })
      .then(result => {
        result.forEach(async imageObject => {
          const objectKey = imageObject.key;

          if (objectKey !== undefined) {
            const signedURL = await Storage.get(objectKey, {
              level: 'private',
              download: false
            });

            this.images.push({ key: objectKey, url: signedURL });
          }
        });
      })
      .catch(err => console.log(err));
  };
}

Some important things to note here is to set the levels to private in both the Storage.list and Storage.get functions. The reason we need to use two functions is because the Storage.list only gives us some information about the objects, such as the unique key in S3. However it does not give use a URL with which we can actually view the object.

For this we need a signed URL. Because we are logged in and we call the Storage.get function with the private level, the Amplify Storage component will check which user is logged in and verify that this user may view this object and create a signed url.

We also created an Image interface which we will use to contain the image key and signed url retrieved from S3. We will store these in an array on the component and loop through these to show the images in image-album.component.html:

<div class="container">
  <div class="row" *ngFor="let image of images">
    <div class="col-lg-2"></div>
    <div class="col-lg-8">
      <img class="album-image" src="{{ image.url }}" />
    </div>
    <div class="col-lg-2"></div>
  </div>
</div>

This simply loops through the imageUrls and shows an image for each. We also add a bit of styling to add the width and a bit of margin in our image-album.component.css:

.album-image {
  width: 100%;
  margin: 8px;
}

This results in the images being viewed on the page like this:

For all the code changes, including the wiring the new component, see this commit.

Adding image removal functionality

In this section we are going to add a button to remove images that we have uploaded. We will first add a removeImage function in our image-album.component.ts:

removeImage = async (key: string) => {
    await Storage.remove(key, { level: 'private' });
    this.images = [];
    this.getAllImages();
  };

We reassign the images array here to force Angular to rerender the image-album component so that we can see that our image as indeed been removed. We then update our image-album.component.html to contain an “x” button for removal next to each image:

<div class="container">
  <div class="row" *ngFor="let image of images">
    <div class="col-lg-2"></div>
    <div class="col-lg-8">
      <img class="album-image" src="{{ image.url }}" />
    </div>
    <div class="col-lg-2"> <!--NEW! -->
      <button class="remove-image-button" (click)="removeImage(image.key)">
        x
      </button>
    </div>
  </div>
</div>

And we add a bit of styling to the button:

.remove-image-button {
  border: 0px;
  background: transparent;
}

And now we have a button that allows us to remove images, which will look something like this:

As always, the changes for this step can be found in this commit.

Setting the maximum number of uploads per user

The final step we want to add for our image upload is to add a maximum number of images per user so that a user does not flood our S3 buckets. We don’t have a property for this in the Amplify Storage component, so we need to build this ourselves. Also, note that the solution here is only a frontend check, there is no actual check on the bucket itself per user.

We make the following changes to our image-upload.component.ts:

import { Component, OnInit } from '@angular/core';
import { Storage } from 'aws-amplify';

const MAX_NUMBER_OF_IMAGES_PER_USER: number = 10;

enum UploadState {
  IDLE,
  UPLOADING,
  UPLOAD_COMPLETE,
  ERROR,
  MAX_REACHED // <--- add this!
}

@Component({
  selector: 'app-image-upload',
  templateUrl: './image-upload.component.html',
  styleUrls: ['./image-upload.component.css']
})
export class ImageUploadComponent implements OnInit {
  //Existing code...

  uploadImage = async () => {
    this.uploadState = UploadState.UPLOADING;
    if (!this.selectedFile) {
      return;
    }
    try {
      //Add this part!
      const userImages = await Storage.list('', { level: 'private' });
      if (userImages.length >= MAX_NUMBER_OF_IMAGES_PER_USER) {
        this.uploadState = UploadState.MAX_REACHED;
        return;
      }

     //Existing code...
    } catch (error) {
      //Existing code ...
    }
  };

  //Existing code...
}

We first add a new state called MAX_REACHED which we will set when this is the case. Inside the uploadImage function we will add a new check where we will first list the objects of the user and check if the length is equal or greater than the max. If this is the case we set the upload state to MAX_REACHED and stop the upload.

In our image-upload.component.html, we add a new error message that is shown in this upload state:

<!---Existing code...-->

<p class="error-text" *ngIf="uploadState === uploadStates.MAX_REACHED">
  Reached maximum amount of uploads. Please remove an image before trying again.
</p>

Now when we try to add the 11th image, we get the following message:

Changes for this step can be found here.

Up next: AI and ML with Amplify Predictions

In this blog, we have used the Amplify Storage category to update our existing application to contain image upload, viewing, and removal functionality per user. In the next article, we will look at using the power of AI and Machine Learning with Amplify Predictions.

Top 8 tips for visiting re:Invent 2023

Evertson Croes — Fri, 20 Jan 2023 11:11:58 +0000

AWS re:Invent 2022 will be an event I will never forget. From the sheer size of the event to the high-quality sessions, conversations, and swag, re:Invent has a lot to offer if you are at all working with AWS.

The event took place in Las Vegas, spanning multiple venues on the strip. AWS did their best to ensure that the event’s magnitude was manageable for the visitoran app that shows everything that is happening that week and by introducing helps you navigate between the venues.
Even with this app handy and all of the re:Invent employees ready to help you at any moment, there are still some things that are good to know before going to the event. In this blog, I will share 8 tips for re:Invent 2023 that I learned from my visit this year.

#1: Reserve your sessions

The sessions scheduled for re:Invent will be made available much earlier than the event, and you will have the option to reserve your seat at these sessions. I highly recommend you take the time to do this and reserve the sessions that you want to go to.

When you finally visit re:Invent, all sessions will have two lines. One for the reserved visitors and the other for the unreserved (walk-up) visitors. Having a reserved seat will not only guarantee you a spot at the session, but it also allows you to do other things and show up 15 minutes before the session and still enter. The people in the walk-up line usually start to gather about 45 minutes before the session and have to stand, and sometimes sit, in line until 10 minutes before the session. Don’t let this happen to you. Reserve your seat!

#2: Get Certified

There are sessions, swag, events, and even a special lounge for visitors that are AWS certified.

I had the most interesting interactions and the most fun at these events. I had conversations with AWS builders around the world. We had discussions about the certification process, how they use AWS at the companies they work, what kind of costs they have, which AWS services they use, and a lot more. We also played games and had some drinks, and eventually added each other on LinkedIn to keep in touch. Don’t miss out on this. Get certified! Any official AWS certification will do.

#3: Join the AWS Community builders

There are also special perks for visitors that are part of the AWS Community Builders group. This gives you access to events and special SWAG. There is an open application twice a year to join. To get into the AWS community builders, you need to:

Write blogs about AWS
Speak at conferences about AWS
Give workshops on AWS technology
Answer questions online about AWS technology
Contribute to AWS open source projects
…anything else that spreads the word and helps others learn about AWS

By joining, you get several benefits next to all of the special access and SWAG at re:Invent:

500$ AWS credit
1 year subscription at CloudAcademy
1 AWS certified exam voucher
Access to Slack which gives you access to AWS community builders and Hero’s
re:Invent discount of 50%
More SWAG
Lots of exclusive access to resources (webinars, beta previews)

#4: Leave room for SWAG

AWS re:Invent has SWAG, a lot of it! Once you visit the Expo, where all the stands are of the event sponsors, you will be overwhelmed with the number of companies that have shown up and are eager to talk to you about their products. Most, if not all stands have some sort of SWAG to give to you. These come in all shapes and sizes. Leave some room in your suitcase!

#5: Vary the type of session you visit

There are several types of sessions to choose from at re:Invent, ranging from typical breakout sessions to workshops. One fact to note is that a breakout session is recorded and can be viewed later on, while sessions such as Chalk or builders sessions do not. If you are struggling to decide which sessions to go to and some of them overlap, consider the session type and choose the non-breakout sessions. You can always watch the breakout sessions later.

For example, at one of the “builder sessions” I was sitting at a table with a Senior AWS architect and other re:Invent visitors to discuss how we can monitor costs on AWS. It was very insightful to see which tools were being used, either AWS native or third party, and also to see the massive number of costs some people are dealing with. One of the tools they discussed in this session is the CUDOS dashboard, which you can deploy via a CloudFormation template that can monitor various aspects of your costs and give you recommendations.

Another type of session was the “Chalk” session, which was very interactive. In one of the sessions, we designed a solution that included using Lambda extensions to debug them from your local development environment, decreasing the feedback loop during Lambda development.

I also visited some breakout sessions, which are available now on Youtube. Some of my favorites include:

Unleash developer productivity with infrastructure from code
- An introduction to Infrastructure FROM code from the CEO of Ampt AWS services.
A close look at AWS Fargate and AWS App Runner
- A walkthrough of the evolution from EC2 instances to AWS App Runner, given by a principal engineer at AWS that has been there from the start.
A day in the life of a billion requests
- A look into how AWS optimized their authentication mechanism to handle half a billion requests per second to IAM. (spoiler: they use a lot of HMAC’s)
Are you integrating or building distributed applications?
- An overview of choices you have to make when building distributed applications and makes clear that the words you use are important. Recommended for anyone in an Architect role.
The architect elevator: Connecting the boardroom and IT
- This talk describes the impact you can have as an architect within a company and gives you tips on how to do this. Also highly recommended for anyone in an Architect role.

#6: Take the venue’s locations into account

As mentioned previously, re:Invent takes place at multiple venues on the Las Vegas strip. Take a moment to check where all the venues are and how long it takes to walk to each venue. AWS offers shuttles between venues, and in my experience, these work well. However, even with the shuttles, if you have to get from the Wynn to the Mandalay Bay, then you are probably going to miss the mark.

#7: Book a hotel close to the Expo

The expo was held at the Venetian. This is the place you want to be when you are not in any other sessions or events. There is a lot to do and see there, such as speaking to people at the several stands about their AWS-related products, collect SWAG, play several types of games, win prizes, attend lightning talks, view product demo’s and get some snacks.

Booking a hotel close to the Expo gives you more opportunities to experience everything it offers.

#8: Register and attend receptions

There is breakfast and lunch included on most days of re:Invent. However, try registering for as many receptions as possible for dinner. These will be announced in the AWS re:Invent app and will be hosted by several of the sponsors. This gives you a good chance to network with different kinds of people. Some of these will offer buffet dinners which is a nice plus.

For some of these events you have to register on time or you won’t get in, and in some cases, the registration starts well before re:Invent, so be sure to keep an eye out online and in your email inbox. If you get an invitation, register immediately as they are quickly full.

Conclusion

I had a great time at re:Invent, and I hope these tips will help improve your re:Invent experience if you choose to attend in person. Of course, you can attend re:Invent virtually as well, for free. Some of these tips, such as getting certified or joining a community, will require you to take action now. It might seem like a lot of work. However, you will be happy once you reap the benefits at re:Invent next year.

The Amplify Series, Part 4: Developing and deploying a cloud-native application with AWS Amplify

Evertson Croes — Fri, 10 Jun 2022 12:31:08 +0000

In this article, we will be using AWS Amplify to create a cloud-native application. We will cover the Authentication, GraphQL API, and Hosting categories of AWS Amplify. We will be using Angular for the frontend. However, the steps taken here should be similar for other frameworks.

We have learned what Amplify is, how Amplify works behind the scenes, and Amplify use cases throughout this series. It is time to see this in action and get hands-on experience using Amplify. At the end of this article, you will have a cloud-native application.

Prerequisites

Before getting started, we need to make sure we have some things set. You need to have the following to be able to follow these instructions and build your application:

An active AWS account.
NodeJS: I used version 14.17.5.
Angular CLI: I used version 13.1.4.
Git: Necessary to check out the example project.
Amplify CLI: I used version 7.6.22.

Configuring Amplify CLI

Before we can start using the CLI, we need to configure the AWS Amplify CLI to use our AWS account. Once you have configured your CLI, we can get started.

Installing dependencies & launching the app

We have created an example AWS Amplify Angular app that you can clone. Check out the start_here branch and start from there. To ensure everything is working, run npm run start. You should see a simple application called “The Amplify App”:

This app is currently a simple Angular app with no associated backend yet. From this point, we will start using the CLI to initialise our project, generate backend resources, and connect them to the frontend.

Initialising the backend

The first command we will run is amplify init. You should see output similar to this:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify init
Note: It is recommended to run this command from the root of your app directory
? Enter a name for the project theamplifyapp
The following configuration will be applied:

Project information
| Name: theamplifyapp
| Environment: dev
| Default editor: Visual Studio Code
| App type: javascript
| Javascript framework: angular
| Source Directory Path: src
| Distribution Directory Path: dist/theamplifyapp
| Build Command: npm run-script build
| Start Command: ng serve

? Initialize the project with the above configuration? Yes
Using default provider awscloudformation
? Select the authentication method you want to use: AWS profile

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html

? Please choose the profile you want to use default
⠴ Initializing project in the cloud...

Once this is done, our Amplify project is created, and we can see several new files in our repository. If you need a refresher of what these files are and how Amplify works, check out part 2 of this blog series: how does AWS amplify work?

If you are creating a public project, it is recommended to add the amplify/team-provider-info.json to the .gitignore, as it contains identifiers to the resources we are using for Amplify. This does not create a security risk since your project is secured with your credentials. If multiple developers are working on the same project, they all need this file.

If everything is working, you should see about 7 changed files.

Configuring the frontend

Now we need to install the relevant Amplify frontend libraries. In this case, we run:

npm install --save aws-amplify @aws-amplify/ui-angular

This will install the amplify library and Angular specific UI elements that we will be using later. After this, we want to configure the Amplify library with our aws-exports.js by adding the following to our src/main.ts:

import Amplify from 'aws-amplify';
import aws_exports from './aws-exports';
Amplify.configure(aws_exports);

Your IDE might complain about the ./aws-exports not having a type definition. An easy fix for now is to add allowJs:true to our tsconfig.json.

Finally, we also need to add the following to src/polyfill.ts:

(window as any).global = window;
(window as any).process = {
env: { DEBUG: undefined }
};

We need to add these since they are used by Amplify but are not present by default since Angular 6.

You should see around 5 file changes after this step.

Adding Amplify Authentication

We are now going to add user authentication functionality to our application.

Generating backend resources for authentication

The first thing we will do is generate backend resources that will help us with authentication by running amplify add auth. You should see output similar to this:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify add auth
Using service: Cognito, provided by: awscloudformation

The current configured provider is Amazon Cognito.

Do you want to use the default authentication and security configuration? Default configuration
Warning: you will not be able to edit these selections.
How do you want users to be able to sign in? Username
Do you want to configure advanced settings? No, I am done.
✅ Successfully added auth resource theamplifyappfdeaa7e5 locally

✅ Some next steps:
"amplify push" will build all your local backend resources and provision it in the cloud
"amplify publish" will build all your local backend and frontend resources (if you have hosting category added) and provision it in the cloud

We should now see some new files added to our project, such as files under amplify/backend/auth, which represent our authentication choices. However, nothing has happened in the backend yet. We need to run amplify push to push our changes to AWS and have CloudFormation create the resources for us:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify push

✔ Successfully pulled backend environment dev from the cloud.

Current Environment: dev

┌──────────┬───────────────────────┬───────────┬───────────────────┐
│ Category │ Resource name │ Operation │ Provider plugin │
├──────────┼───────────────────────┼───────────┼───────────────────┤
│ Auth │ theamplifyappfdeaa7e5 │ Create │ awscloudformation │
└──────────┴───────────────────────┴───────────┴───────────────────┘
? Are you sure you want to continue? Yes
⠋ Updating resources in the cloud. This may take a few minutes...

Adding the authentication component to the frontend

We will be using the Amplify Authenticator UI component to implement authentication in the frontend. We already installed this previously however now, we still need to add it to src/app/app.module.ts:

//Other imports
import { AmplifyAuthenticatorModule } from '@aws-amplify/ui-angular'; // <-- Add this

@NgModule({
declarations: [
//Existing declarations
],
imports: [
//other imports
AmplifyAuthenticatorModule // <-- Add this
],
// Other stuff
})
export class AppModule {}

We are going to start off by simply protecting our entire application with the Amplify authenticator. To do this, add the following to src/app/app.component.html:

<amplify-authenticator><!-- <--Add this -->
<app-header></app-header>
<div class="content-container">
<router-outlet></router-outlet>
</div>
<app-footer></app-footer>
</amplify-authenticator> <!-- <--Add this -->

And we also need to import the default styling in our src/app/styles.css:

@import "@aws-amplify/ui-angular/theme.css";

/* other styles */

If you run your application now, you should see the Amplify authenticator:

You can use this to create an account and log in to see the application. It is a fully-featured authenticator with registration, sign-in, forgot password, and email activation. It also gives feedback when errors occur.

There are several options to customize this UI. You can find out more about the Amplify Authenticator in the documentation.

Once you have created an account, you should be able to log in to the AWS console, navigate to the Cognito service and see a user pool with the name of your project. Inside that user pool, you should see your new account:

Adding signout functionality

We also want to be able to sign out of our application. First we add the actual button in header.component.html:

<nav>
    <!-- other existing code -->
    <button class="aws-button" (click)="signOut()">Sign out</button> <!--  <-- Add this -->
</nav>

And then, we add our sign out logic, which we get directly from Amplify, in our header.component.ts:

import { Auth } from 'aws-amplify'; // <-- Add this

export class HeaderComponent implements OnInit {

// Other existing code

    signOut() { // <-- Add this
      Auth.signOut();
    }
}

And now, we have a sign-out button which we can use to sign out and go back to the Amplify Authenticator.

User data

We will add a Welcome <<username>> text in the header. We can use the Amplify Auth library to get this data. We will begin by creating an Angular service which we will call UserService, which will handle all of our logged-in user’s needs.

In the terminal, run the following at the root of your project:

ng generate service services/shared/user

We will update the new service in the following way:

import { Injectable } from '@angular/core';
import { Auth } from 'aws-amplify';

export interface UserInfo {
  email: string;
  username: string;
}

@Injectable({
  providedIn: 'root'
})
export class UserService {
  constructor() {}

  async getCurrentUserInfo(): Promise {
    const userInfoResponse = await Auth.currentUserInfo();
    return {
      email: userInfoResponse.attributes.email,
      username: userInfoResponse.username
    };
  }
}

It makes use of the Amplify Auth library to get information about the current user. We then make some changes in our header.component.ts file to call this function:

import { UserService, UserInfo } from '../../services/shared/user.service'; //<--- Add this

export class HeaderComponent implements OnInit {
  //other code
  currentUserName: string = ''; //<--- Add this

  constructor(public router: Router, private userService: UserService ) { //<--- Add userService
    //other code
  }

  ngOnInit(): void { //<--- Add this     this.userService       .getCurrentUserInfo()       .then((userInfo: UserInfo) => {
        this.currentUserName = userInfo.username;
      })
      .catch(error => {
        console.log('Error while obtaining user: ', error);
      });
  }
}

And now that we have variable in the header component with the current username, we can display this in the header.component.html:

<nav>
<!-- other code -->
    <span class="welcome-text">Welcome {{ currentUserName }}</span> <!-- <--- add this -->
    <button class="aws-button" (click)="signOut()">Sign out</button>
</nav>

And finally we add some styling in header.component.css so that we can actually see the text on the dark background:

.welcome-text {
  color: white;
  margin-right: 16px;
}

And now we have a text that shows us the username of the user that is logged in:

Check out the Amplify Auth documentation for details.

We’ve changed several things now:

Connecting the backend with GraphQL

In this section, we will add a GraphQL API for our application, which will replace the current in-memory mock data being used for the API page in our application. If you click through the API tab, you will see that we have a list of Posts that can all have a list of Likes and Comments. We will be modeling this in GraphQL.

Generating backend resources for the API

To start, we need to add a resource endpoint:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify add api
? Select from one of the below-mentioned services: GraphQL
? Here is the GraphQL API that we will create. Select a setting to edit or continue Authorization modes: API key (default, expiration time: 7 days from now)
? Choose the default authorization type for the API Amazon Cognito User Pool
Use a Cognito user pool configured as a part of this project.
? Configure additional auth types? No
? Here is the GraphQL API that we will create. Select a setting to edit or continue Continue
? Choose a schema template: One-to-many relationship (e.g., “Blogs” with “Posts” and “Comments”)

⚠️ WARNING: Some types do not have authorization rules configured. That means all create, read, update, and delete operations are denied on these types:
- Blog
- Post
- Comment
Learn more about "@auth" authorization rules here: https://docs.amplify.aws/cli/graphql/authorization-rules
GraphQL schema compiled successfully.

Edit your schema at /Users/evertsoncroes/Documents/development/private/theamplifyapp/amplify/backend/api/theamplifyapp/schema.graphql or place .graphql files in a directory at /Users
/evertsoncroes/Documents/development/private/theamplifyapp/amplify/backend/api/theamplifyapp/schema
✔ Do you want to edit the schema now? (Y/n) · yes
✅ Successfully added resource theamplifyapp locally

✅ Some next steps:
"amplify push" will build all your local backend resources and provision it in the cloud
"amplify publish" will build all your local backend and frontend resources (if you have hosting category added) and provision it in the cloud

It is important to change the authentication method from API key to Amazon Cognito User Pool to use the Auth resources we created in the last section.

We now have some new files generated for us by the Amplify CLI. We are going to start by editing the amplify/backend/api/schema.graphql to look as follows:

type Post
@model
@auth(rules: [{ allow: owner }, { allow: private, operations: [read] }]) {
id: ID!
title: String!
description: String
likes: [Like] @hasMany
comments: [Comment] @hasMany
}

type Like
@model
@auth(rules: [{ allow: owner }, { allow: private, operations: [read] }]) {
id: ID!
post: Post @belongsTo
}

type Comment
@model
@auth(rules: [{ allow: owner }, { allow: private, operations: [read] }]) {
id: ID!
post: Post @belongsTo
content: String!
}

In this example, we have defined 3 GraphQL Object types for Post, Likes, and Comments. We don’t specify a date field because we get a createdAt and updatedAt field for each type by default.

The Amplify specific parts of this schema are the directives, which you can notice by the @ prefix. The directives used here are:

@model: This creates a DynamoDB table to back this model. In this case, 3 tables will be created.
@auth: These are authorization rules for the type. The rules described here are:
- The owner (creator) of a record is allowed to perform all operations on that record
- An “owner” field will be added to each item in the DB, which contains the username of the logged-in user that created the item
- Only logged in users (private) can read the records for this type
@hasMany: This creates a one-to-many relationship with another type. In our example above, Posts have many comments and likes.
@belongsTo: This creates a many-to-one relationship with another type. In our example above, comments belong to one post, and likes belong to one post

You can learn more about directives or authorization rules in the Amplify documentation.

After customizing our schema we run amplify push and select yes. We are then asked a few questions related to graphql:

? Do you want to generate code for your newly created GraphQL API Yes
? Choose the code generation language target angular
? Enter the file name pattern of graphql queries, mutations and subscriptions src/graphql/**/*.graphql
? Do you want to generate/update all possible GraphQL operations - queries, mutations, and subscriptions Yes
? Enter maximum statement depth [increase from default if your schema is deeply nested] 2
? Enter the file name for the generated code src/app/API.service.ts

This will generate a lot of front-end code specific to our schema so thatuse we can easily our GraphQL backend.

Connecting the frontend to the API

A few files have been generated that are important to cover. First of all, there is the API.service.ts. This file contains all generated types and statements that can be used with the GraphQL API and injected as an Angular Service into Angular components and services.

Secondly, we also have a directory now called graphql in the root of our project. This file contains generated GraphQL Queries, Mutations and Subscription, and a JSON representation of our GraphQL schema. These files are used as input to generate API.service.ts. We will look at these files later in the article.

Filling the data source

We will start by updating our post.service.ts to save new posts to our Amplify backend instead of in the mockObject. We will make the following changes:

//Other imports
import { APIService } from 'src/app/API.service'; // <--- Add this

@Injectable({
  providedIn: 'root'
})
export class PostService {
  //other code

  constructor(private api: APIService) { // <--- Add api to constructor
  }

  addPost(title: string, description: string) { // <--- replace current addPost with new code
    this.api.CreatePost({
      title,
      description
    });
  }

  //other code
}

Here we import the generated API service and use one of the generated functions, CreatePost, to create a new post item to our backend. If you search for the definition of the CreatePost function in src/app/API.service you can see which parameters it expects. In this case adding a title and description is enough.

Now when we add posts, they will be persisted.

Retrieving data from the backend

The next step is to retrieve all our posts from the backend. We will make the following changes to our post.service.ts:

// other imports
import { APIService, Post as AmplifyPost } from 'src/app/API.service'; // <--- Add this new import

@Injectable({
  providedIn: 'root'
})
export class PostService {
  private posts: BehaviorSubject<Post[]> = new BehaviorSubject<Post[]>([]); // <--- remove mockposts and its usage completely
  private postsData: Post[] = [];

  constructor(private api: APIService, private userService: UserService) {
    this.setOnPostCreateSubscription();
  }

  // Other code
  
  //Update this function
  getAllPosts(): Observable<Post[]> {
    this.api.ListPosts().then(response => {
      const responsePosts: Post[] = [];
      response.items.forEach(item => {
        const post = this.convertToPost(item as AmplifyPost);
        responsePosts.push(post);
      });

      this.posts.next(responsePosts);
    });

    return this.posts.asObservable();
  }

  //Add this function
  private convertToPost(amplifyPost: AmplifyPost): Post {
    const {
      id,
      title,
      description,
      owner,
      createdAt,
      likes,
      comments
    } = amplifyPost;

    const likesItems = likes ? likes.items : undefined;
    const commentsItems = comments ? comments.items : undefined;

    return {
      id,
      title,
      description: description ? description : '',
      author: owner ? owner : '',
      date: new Date(createdAt),
      likes: likesItems ? likesItems.length : 0,
      comments: commentsItems ? commentsItems.length : 0
    };
  }
}

We are doing a few things here:

Importing the generated Post interface and giving it an alias since Post already exists and is used for our Post component UI model
Removing the mock data completely since this service will now be serving data from the Amplify backend
Using the listPosts generated function to get all posts in our backend.
Converting the posts retrieved from the amplify backend to the Post model we want to use in our UI. A significant difference here is that we want to count the number of likes and comments and return numbers.

If we run our app now, we should now see new data retrieved from the backend. If we add a new post and refresh the page ,we should see the latest post in the list.

Subscribing to data

It would be nice to have the new post show up in the list immediately after it is added. One way to achieve this is to call getAllPosts after the addPosts was successful. There is a better way, though: Amplify GraphQL also allows us to subscribe to certain events.

In this case, we can subscribe to the event of a post being created by making the following changes to our post.service.ts:

import { UserService, UserInfo } from '../shared/user.service'; // Add this import

@Injectable({
  providedIn: 'root'
})
export class PostService {
  private postsData: Post[] = []; // <-- add this

  constructor(private api: APIService, private userService: UserService) {
    this.setOnPostCreateSubscription(); // <-- add this
  }

  //Add this function
  private async setOnPostCreateSubscription() {
    const userInfo: UserInfo = await this.userService.getCurrentUserInfo();

    if (userInfo) {
      this.api.OnCreatePostListener(userInfo.username).subscribe(response => {
        const responseData = response.value.data;
        if (responseData && responseData.onCreatePost) {
          const post = this.convertToPost(
            responseData.onCreatePost as AmplifyPost
          );
          this.postsData.push(post);
          this.posts.next(this.postsData);
        }
      });
    }
  }

  getAllPosts(): Observable<Post[]> {
    this.api.CustomListPosts().then(response => {
      const responsePosts: Post[] = [];
      response.items.forEach(item => {
        const post = this.convertToPost(item as AmplifyPost);
        responsePosts.push(post);
      });

      this.postsData = responsePosts; // <-- add this
      this.posts.next(responsePosts);
    });
    return this.posts.asObservable();
  }
}

We made these changes:

Import the UserService we created in the last section. This is needed because of a limitation in Amplify GraphQL subscription (see below).
Created an array that holds the state of the latest data retrieved. We need this since the subscription only returns the new post added. We need to add the newly created post to this list and return it to the component.
We call the onCreatePostListener with the username of the currently logged in user and we convert the response of this subscription to our Post model object, similarly to how we did this for the query.

Amplify GraphQL limitation

Currently it is not possible to have the owner auth rule in your GraphQL schema and have a subscription on an object without supplying the owner username. If you want to be able to have a subscription on all objects of a type, regardless of who created it, you need to remove the owner auth rule in your schema. However, this means that you will no longer get the owner field in all of your items in the database and that any logged in user can also update and delete posts that don’t belong to them.

For the sake of having a working subscription example, we have created a subscription for the current user, meaning you will only get updated for posts that you post yourself. Hopefully in the future we will be able to have more flexibility regarding subscriptions. Nevertheless, this example should still show how easy it is to setup subscriptions and there are still several use cases where this might be useful.

Likes and comments

For the Like and Comment services we followed steps similar to those followed for the Post. You can view all of these steps in the Git commits we will list at the end of this section. However, there are some key points we still want to cover that we encounter when migrating likes and comments to the Amplify backend.

GraphQL query with filters and pagination

When we want to query the likes or comments, we only want to query them if they belong to the Post that we are currently looking at in the frontend. Luckily, the generated functions we use to query our backend come with built-in filtering and pagination functionality.

If we look at the definition of the ListLikes function in the API.service.ts, we can see the following signature:

async ListLikes(
    filter?: ModelLikeFilterInput,
    limit?: number,
    nextToken?: string
  ): Promise<ListLikesQuery> {

 //code

 }

The ModelLikeFilterInput contains options to filter the results based on several conditions. Click through them to see all of the possibilities. We can also see a limit and a nextToken parameters which are used for pagination. Since we did not build pagination in this application yet, we will refer to the pagination documentation.

To query only the likes that belong to a certain post, we use the following code:

getLikesForPostId(postId: string) {
    this.api.ListLikes({ postLikesId: { eq: postId } }).then(response => {
    //other code

Custom GraphQL Queries, Mutations and Subscriptions

If you follow the patterns we have shown up to now and have posts, likes and comments using the Amplify backend, you will notice that all posts still show 0 likes and comments on the post overview. This is a bug, and has to do with the values that are retrieved in the generated GraphQL query used in the listPosts function.

If we check the definition of the query in the src/graphql/queries.graphl we will see the following:

query ListPosts(
  $filter: ModelPostFilterInput
  $limit: Int
  $nextToken: String
) {
  listPosts(filter: $filter, limit: $limit, nextToken: $nextToken) {
    items {
      id
      title
      description
      likes {
        nextToken
      }
      comments {
        nextToken
      }
      createdAt
      updatedAt
      owner
    }
    nextToken
  }
}

We can see that for the likes and comments, only the nextToken field is being retrieved. The items field is not being retrieved at all, which is why our frontend is defaulting to 0. Thankfully, we can define our own queries.

We can create a new file called src/app/custom-queries.graphql with the following content:

query CustomListPosts(
  $filter: ModelPostFilterInput
  $limit: Int
  $nextToken: String
) {
  listPosts(filter: $filter, limit: $limit, nextToken: $nextToken) {
    items {
      id
      title
      description
      likes {
        items {
          id
        }
      }
      comments {
        items {
          id
        }
      }
      createdAt
      updatedAt
      owner
    }
    nextToken
  }
}

We now query the items for likes and comments and only retrieve the ids, since we only want to count them. Once we add this file, we can run the following in the terminal:

amplify codegen

This will generate new code that you can use in your frontend without having to run amplify push. Now we can update our post.service.ts to make use of this new query:

getAllPosts(): Observable<Post[]> {
    this.api.CustomListPosts().then(response => { // <-- updated here
      //code

If we run the application now we should see the correct counters for likes and comments.

Custom GraphQL Resolvers

In our current example we retrieve likes and comments and we count them in the frontend to show the counters. We could also update our GraphQL schema for Post to include a likesCount and commentsCount fields and define custom logic for these fields.

This would let the backend calculate these numbers for us and return them to the frontend. A demo of this would be too long for this article, so we will refer to the documentation for AWS Lambda resolver configuration, which explains how to set this up.

We’ve introduced quite some changes:

Hosting our application

Now that we have our application working locally, it is time to host it on AWS so that it is available online. We are going to do this by adding the Amplify hosting category. Before we do that, we need to do these steps:

Log in to the AWS console with your default browser.
Push all your code to Git.
Update the initial budget in angular.json to 2mb.

We will run the following command to add hosting:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify add hosting
? Select the plugin module to execute Hosting with Amplify Console (Managed hosting with custom domains, Continuous deployment)
? Choose a type Continuous deployment (Git-based deployments)
? Continuous deployment is configured in the Amplify Console. Please hit enter once you connect your repository

This will open the AWS console that will enable us to connect our repository to the CI/CD pipeline:

Click on the Hosting environments tab and select your Git repository:

Click on connect branch. Once you are authenticated with your Git repository, select the repository and branch where the latest version of your code exists and click on Next.

On the next page it is important that you select an environment to use for this deployment. In this case we have only created a dev environment, so we will use that:

In case you don’t have an existing service role for Amplify projects, click on Create new role to generate one and click on the refresh button to see it appear as an option.

If you scroll to the bottom you will see the default build settings. For now these will work, however if in the future you want to extend the build to include more phases or steps you can always change this.

When we click on next we will get a summary of the options we selected. Review them and click on Save and deploy.

From this point on, everytime you push to the develop branch a build will start and the live application will get updated. This is what it looks like when it is building:

You can click on any of the phases, such as provision to see the detailed logging of what is happening:

When it is done building and deploying, we can see that all steps have passed and that there is a link to test out our app:

Configuring redirects for our SPA

If you click on the link you should see your application where you can log in and should see the main page. However, if you click on API you will get an access denied error. For single page applications we need to add an extra setting in the Amplify console in our project related to rewrites and redirects:

The settings are:

Source address: </^[^.]+$|\.(?!(css|gif|ico|jpg|js|png|txt|svg|woff|woff2|ttf|map|json)$)([^.]+$)/>.
Target address: /index.html.
Type: 200 (Rewrite)
Country: (leave empty).

For details, refer to the Amplify documentation for single page application redirects.

(Extra) Linking a domain name to your deployment

One extra step you could take is to link a domain name to one of your deployments. In this case we are going to create a new environment for our project, link it to the master branch and then link the domain name “theamplifyapp.com” to that deployment.

To start off, I will run the following command in the terminal:

Evertsons-MBP:theamplifyapp evertsoncroes$ amplify init
Note: It is recommended to run this command from the root of your app directory
? Do you want to use an existing environment? No
? Enter a name for the environment prod
? Choose your default editor: Visual Studio Code
Using default provider  awscloudformation
? Select the authentication method you want to use: AWS profile

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html

? Please choose the profile you want to use default
Adding backend environment prod to AWS Amplify app: d1ekyrd95b627y
⠴ Initializing project in the cloud...

Once that is done we can run amplify push and follow the steps we made for the dev environment.

After that, we can go into the Amplify console, click on General, scroll to the bottom and click on connect branch. There we will select the master branch and the prod environment:

Then we click on next and save and deploy and wait for the build to be successful.

After that is done, we can go to Route53 in the AWS console and register a domain name. Note that this will cost money! In this case I have registered the domain theamplifyapp.com.

Back in the Amplify console, click on the Domain management tab and on Add domain. We should find our registered domain in the available domains and select it. Then we click on Configure domain and set it to the master branch build:

Once we click on Save the process should get started. When it is complete, we can visit our application on our brand new domain!

We made two major changes:

Up next…

With just a few Amplify commands and code changes we have:

Created a cloud-native application…
Protected with authentication…
Backed by a GraphQL backend…
With a fully configured CI/CD pipeline…
Hosted on the AWS cloud…
Connected through a registered domain name

For each of the categories taken there are still plenty of customization options to explore. However, hopefully it has become clear how powerful Amplify can be.

In the next installment of this series we will continue working on our application and we will add the Amplify Storage category. We will use this to create an image library where we can upload images.

The Amplify Series, Part 3: Why should you use AWS Amplify?

Evertson Croes — Fri, 21 Jan 2022 13:36:11 +0000

Now that you know what AWS Amplify is and have a broad overview of how it works, we will look at several reasons you might consider using it. We will also look at scenarios where Amplify might not be the best choice. AWS Amplify is a powerful tool. However, you should always try to use the right tool for the job! Whether the right choice is Amplify or another tool.

Amplify has evolved into a useful and mature toolset for creating cloud-native web and mobile applications. Having Amplify in your developer toolbelt will increase your productivity in different scenarios. Be it developing your next application, creating a quick prototype, or learning/teaching AWS. Let’s look at why you might want to use AWS Amplify.

Increase speed, reduce risk: write less hand-crafted code

The primary reason to use AWS Amplify is that it increases your business speed and agility. This is achieved by greatly reducing the amount of code you need to write and manage to achieve cloud-native functionality. In part 1, we already listed all of the functionality available in AWS Amplify. However, that was just a brief overview. In this section, we want to zoom in on some of the functionality and advantages that impress us the most and end up using the most in our projects.

Authentication

One of the most valuable categories in the Amplify suite is the Auth category. It provides us with rich authentication functionality backed by AWS Cognito. After you use this for the first time, you will never want to write your own authentication mechanisms ever again. This category even comes with an authentication UI that you can optionally use to speed up development even more, and it is completely customizable:

Once the auth category is set up, it will create an AWS Cognito user pool to register your users. The Amplify SDK will provide several helper functions to register, sign in and sign out your users. There is also forgot-password and email activation functionality out-of-the-box.

Besides creating a user using an email and password combination, you can easily set up federated sign-in with Google, Facebook, Apple, or any provider that supports Open-ID connect and SAML.

One other nice feature to notice in this category is that it will handle authentication for the other categories such as API and Storage once you have it set up. This means that you do not need to handle any token management yourself.

GraphQL

While the REST version of the Amplify API category also provides a lot of functionality, including a REST API, Lambda function, and DynamoDB, we have decided to highlight the GraphQL version as it is a prime example how much AWS Amplify can help you with.

If you are familiar with GraphQL, you know that you can define your API in a GraphQL schema. What Amplify adds to this is several annotations called GraphQL directives that generate functionality. The following is an example of such a schema:

Just by creating this schema, we will get the following generated for us:

@model: DynamoDB tables for Show and Review are generated. GraphQL Query, Mutation, and Subscription client stub code for Show and Review
@auth: 403 http status codes when the auth rules are broken. In this example, only users that are logged in (“private”) are allowed to create, read, update and delete shows. There is also the possibility of making more complex authorization rules, such as allowing only users of a particular group to perform actions.
@connection: References from Show to Review and vice versa
@function: GraphQL queries for “reviewScore” for “show” routes to a separate Lambda function instead of going directly to the database. In this way, you can still customize the logic in the backend instead of just building CRUD.

Visit the AWS Amplify docs to find out more about Amplify GraphQL directives

Hosting and CI/CD

The final part we want to highlight is the entire hosting and CI/CD that you can set up for your project in just a few commands. By simply running “amplify add hosting” and following a few instructions, you can set up an entire CI/CD pipeline for your repo that deploys the backend and hosts the frontend on a public URL.

Every part of the pipeline is customizable, and setting up redirects and HTTPS with a domain name is a piece of cake. You can even spin up different environments per branch to test them.

Empower front-end engineers: JavaScript front- and back-ends

We have noticed while using Amplify that it has allowed our front-end engineers to expand their reach in development by being able to contribute to the backend since it is also written in JavaScript.

While Amplify supports Lambda functions in other languages such as Java, choosing for JavaScript while also building your frontend in JavaScript means that you develop your entire application with the one language all frontend engineers know. This will allow Frontend engineers to pick up whole vertical issues in your project to handle changes to the entire stack.

Note that you can choose to ignore JavaScript completely and build an Android mobile app with Java Lambda’s in the backend in Amplify. The advantage mentioned here does not hold in this case.

Innovate at speed: prototype to reduce time-to-value

Prototyping is one of the best ways to determine if your product/solution will solve the problems you are trying to solve. If you can test your ideas and get feedback as fast as possible, you will innovate quickly.

While using paper prototypes or interactive mockups is a fast way to get user feedback, you can only reach the number of people you have time to test with. If you want to get an actual prototype up and running in no time so that it can be shared via social media and tested by several users, then Amplify can be used to skip all of the setup and let you focus on building the prototype.

If you combine this with analytics and surveys, you will get information from a more extensive user base should that be necessary.

Accelerate cloud proficiency: leverage AWS best practices and patterns

AWS has almost 200 services available at the moment. This can be very intimidating for someone trying to start their cloud journey. AWS Amplify only uses a subset of these services and guides you in creating and configuring the services.

One of the strengths of Amplify is that you can create an entire cloud-native application without having to know what is happening under the hood. However, learning what happens under the hood of AWS Amplify is an excellent way to start learning about cloud computing since the scope of services is much smaller, and you can take it step-by-step based on the categories.

When you are done building your first cloud-native Amplify application and know what is happening in the background, you will have a sound base of knowledge and experience to build upon.

Keep options open: extend Amplify with CDK

One of the most common questions is when we should use Amplify or CDK when starting up a cloud-native AWS project. By now, you have an idea of what AWS Amplify is. If you have never heard of CDK before, our colleague wrote an introduction blog post about it.

The primary objective of CDK is to allow developers to write infrastructure-as-code in a programmer-friendly language instead of CloudFormation. Amplify wants to abstract as much as possible from the backend infrastructure and Cloudformation, while CDK has nothing to do with the frontend. Since they have different goals, they have different scenarios where you should pick one over the other.

However, since the introduction of Amplify Extensibility, your options have become somewhat simpler. You can build your frontend using Amplify, extend it with CDK and even export your Amplify project as a CloudFormation templates to use in your existing CDK projects. Picking one over the other is no longer an binary exercise. Instead, we should explore when to leverage which option.

When should you not use AWS Amplify?

Before Amplify Extensibility, which allows you to use AWS CDK to define AWS services you want to use in your Amplify application that is not present in the several Amplify categories, my advice was always:

“If you can map your main success use cases to the Amplify categories, then you should use Amplify. Otherwise, you should avoid using it.”

However, this advice has become obsolete since we can now use any AWS service in our Amplify applications thanks to Extensibility. There are still some scenarios where you shouldn’t use Amplify:

Non-AWS or multi-cloud projects: AWS Amplify can only target the AWS cloud platform.
Non-fullstack projects: if you creating pure front-end or back-end projects, Amplify might not be the most effective choice.
Misfit with existing architecture: if fitting an AWS Amplify project into your existing landscape would require massive effort or does not align with existing architectural principles, it might not be the most logical choice. Maybe you should start with convincing your enterprise architect of Amplify's value first.
No clear advantage: if large parts of Amplify's functionality are already in place (e.g., slick build and deploy pipelines, or a library of similar building blocks), then the added value of Amplify might not be so great. But that's good news, right?

Up next…

Hopefully, this blog has given you even more reason to start working with AWS Amplify. Now that we have the high-overview and background information out of the way, it is time to get our hands dirty! In the following blog posts, we will be creating an AWS Amplify application, and we will take a closer look at several Amplify categories.

The Amplify Series, Part 2: How does AWS Amplify work?

Evertson Croes — Wed, 22 Dec 2021 10:42:59 +0000

In the previous blog, we got a high-level overview of AWS Amplify. In this article I will examine how AWS Amplify works and explain the "magic" behind the scenes. While one of the advantages of Amplify is that you don’t need to know any of this to develop a cloud-native application, it is essential to understand its inner working if you want to do more than just quick scaffolding.

I have worked on several Amplify projects without digging deep to get effective. So if you want to get to just building a cloud-native application, you can skip this one. However, for those of you who stay, we will be covering the foundation on which Amplify is built upon, the concept and technologies used, and describe what actions happen in the background when you run specific commands in the Amplify CLI. It is important to note that the examples we give in these articles are very web app-oriented to keep the articles shorter. However, Amplify also supports mobile development with Android, iOS, and hybrid frameworks, and for the most part, the information here is still relevant.

Infrastructure as Code (IaC)

To explain how AWS Amplify works, we first need to discuss the concept of "Infrastructure as Code".

Before IaC, we would probably log in on a cloud console or web portal of some sort and start configuring our infrastructure by clicking around. Additionally, the cloud provider might have a CLI or another tool to help us provision our infrastructure. After many clicking and cli commands, we finally have our first version up and running.

After testing this setup, we are ready to go to production. Here is where we encounter one of the first problems that IaC solves: How do we replicate the test environment we provisioned and tested? One option is to follow all the steps we did to create a replica. However, as you can already tell, this is very error-prone, and missing even one step might make a big difference.

With IaC, we solve this issue by describing these steps we made into some form of code. Once we have this in code, we can easily create a copy of the infrastructure using a provider that understands the code and can provide us with resources. There are also other benefits to IaC. To learn more about it, check out this blog post or this short video.

Many tools provide IaC functionality, such as Terraform, Puppet, Google Cloud Deployment Manager, and Azure resource manager, to name a few. When it comes to AWS, we use AWS Cloudformation.

AWS CloudFormation

AWS Cloudformation is the Infrastructure as Code solution provided by Amplify. We can define our cloud environment, meaning the resources and their dependencies, in so-called "CloudFormation templates". These templates are written in JSON or YAML. CloudFormation can take such a template and create a CloudFormation Stack, a set of related resources. For CloudFormation to find the template, it must be uploaded to S3.

However, the good news is that Amplify will do all of the steps above for you. You just need to answer a few questions about what kind of functionality you need for your cloud-native app. Amplify will generate CloudFormation templates based on these answers, deploy them to S3 and use CloudFormation to create, update or delete the stack. We can log in to AWS and go to CloudFormations to look at our stacks at any time. Here is an example of a CloudFormation template generated by Amplify:

Some items in the example above are minimized, but we can see that we are declaring an API resource with a path "/players" and "/achievements". The entire file is 2200 lines long, only for the Amplify API category. Learning to do this by hand is a lot of work and error-prone. That is why several tools generate CloudFormation, such as Amplify, AWS CDK, and AWS SAM. Which tool you should use will be covered in the next blog. For now, it is essential to understand the basics of CloudFormation.

Configuring AWS Amplify CLI

Before you start using the Amplify CLI, you need to configure it to know which account it can use to create AWS resources using S3 and CloudFormation. You can do this by running "amplify configure" in the command-line terminal. This will open a browser window for you to log in to the AWS console and walk you through the steps of creating an IAM account that has enough access to do everything that the Amplify CLI needs to do. At the end of all of the steps, you must give the profile a name. This name will be used in the CLI moving forward with Amplify, and at some points, the CLI will ask you which profile you want to use for which commands.

Once this is done, the CLI will use these credentials to communicate with AWS to generate cloud resources via CloudFormation. Here is a diagram showing the actions that happen when you first configure your CLI and how the credentials are used to access CloudFormation and S3:

Initialising an Amplify project

When your CLI is configured, you can start creating your Amplify project. This is done by navigating to the root of your project and running "amplify init". The CLI will ask several questions, one of which is related to the credentials we configured. Once we select the correct profile, Amplify will work and perform several actions to create the Amplify project.

Changes in AWS

After running the amplify init command, the CLI will create an S3 bucket to store the CloudFormation templates, and it will create a CloudFormation stack that will point to the S3 bucket. Here is an example of a stack built after running amplify init:

As we can see, the DeploymentBucket is present, which will hold our CloudFormation templates. There are also two IAM roles created for the project. One for authorized users and one for unauthorized users. Once we begin adding more Amplify functionality and setting up authorization rules, these IAM roles will be updated to match what we configure via Amplify.

Another action that is taken by the CLI when running Amplify init is the creation of an Amplify project in the Amplify console:

This will become relevant once we start looking into hosting and adding CI/CD for our project.

Changes in the project repository

The CLI also generates and updates several files in our repository, reflecting our choices made in the Amplify CLI. An extensive list of files generated by Amplify can be found here; however, here is a summary of the files changed if you init for an Angular application:

amplify/cli.json: Feature flags for the CLI
amplify/README.MD: A list of links to helpful resources
amplify/team-provider-info.json: Information needed so that other team members can use Amplify. This file can be added to git if running a private application. However, it is advised to remove it or add it to the gitignore if it is a public project. Note: Even if someone gets the information in this file, they would still need the correct credentials to use the information.
amplify/.config/..: Configuration options set during the "amplify configure" command
amplify/backend/backend-config.json: Information about resources and how they connect.
amplify/hooks/...: Command hooks that can be used during the Amplify lifecycle, such as "pre-push", "post-add-function" etc.
src/aws-exports.js: This file only exists for JS projects and is used by the JS libraries to know which resources they should communicate with.
.gitignore: This file is updated by the Amplify CLI to ignore certain generated files and should not be stored in Git.

These changes should all be stored in Git to have a good starting point for your project. In general, changes made by the Amplify CLI should be committed to Git because those are the changes in your Infrastructure as Code setup that Amplify is updating for you based on your CLI choices.

Adding backend functionality to project

Once the project is initialized with Amplify, we can add backend functionality.

Backend functionality

When we talk about backend functionality, we mean AWS Cloud services that will be generated by the CLI and consumed by our frontend application. For example, adding the Amplify (REST) API category will make use of AWS API Gateway. Adding the Amplify Auth category will make use AWS Cognito. Here is a diagram that shows a deployment of a REST backend created with AWS Amplify:

Here we can see that the CLI generates a set of AWS resources. Each resource is part of an Amplify category. On the right side we can see that our frontend application will make use of the Amplify SDK to use these resources.

Using the CLI

We can add backend functionality by running "amplify add <>" in the CLI. In this case, if I run "amplify add auth" I will get the following questions:

Note that this is one of the more straightforward functionalities to add. When adding API, for example, you will have to answer many more questions. Once we are done running this command, there will be changes in our project:

amplify/team-provider-info.json: It will now contain a "categories" object containing the "auth" category with identifiers of the resource.
amplify/backend/backend-config.json: It will now contain an object called "auth" with information related to the AWS service and how it needs to be configured, in this case, AWS Cognito.
amplify/backend/auth/<>/cli-inputs.json: This file contains the choices you made via the CLI for the auth category. This is the file that will be committed in Git with the state of the auth category for this project. This is much better than adding the CloudFormation templates themselves to Git, as that would make fixing merge conflicts harder.
amplify/backend/auth/<>/build/<>-cloudformation-template.json: This is the actual CloudFormation template which will be used. This file is already added to the .gitignore by Amplify and will be regenerated when there are relevant changes.
amplify/backend/auth/<>/build/parameters.json: Contains environment specific parameters for the CloudFormation template. It should also be ignored in Git.

It is important to note that we have not yet done anything in AWS. These changes all remain local until the next step.

Pushing backend changes to AWS

After adding and updating functionality that we need in our application via the CLI, we can push the local changes to AWS running "amplify push". This is where we will be making changes in AWS and generating the resources that will be needed to support the functionality we want. With this command, we will be generating several resources into our CloudFormation stack by just answering questions in a CLI.

When running the command, the CLI will compare the state of the infrastructure in the S3 deployment bucket and the local changes and give a preview of the changes that will happen if the push continues. In the case of the auth category we added in the last section; the preview would look as follows:

We can see that new resources will be created for the auth category. If we choose "yes" then the CLI will update the S3 bucket with the new CloudFormation templates and use CloudFormation to create/update the stack for our Amplify project. One other important thing to note is that once the CLI starts pushing the changes to AWS, it will also update the aws-exports.js file with the new references so that the frontend libraries can make use of this.

At any point, we can run amplify status to see the state of your current changes. After pushing the changes and running amplify status, we can see that we no longer have any changes:

We can also check out our CloudFormation stack to see all the new resources created.

This is the primary development cycle for working with AWS Amplify using the CLI. In short, we:

Make local changes by running "amplify add <>" or "amplify update <>"
We run "amplify push" and check if the changes make sense
We click on "Yes" to let the push continue
(Optional) We check CloudFormation to see if the stack is in the "CREATE_COMPLETE" or "UPDATE_COMPLETE" status

Connecting backend and frontend

Besides the CLI, Amplify also provides libraries so that your frontend application can make use of the generated resources in an easy way. We need to inform the frontend libraries of the backend resources we have generated and how to find them.

To get this working, we first need to install the libraries. You can find tutorials for all of the integrations here. For Angular, we can run:

"npm install --save aws-amplify @aws-amplify/ui-angular@1.x.x "

Furthermore, we need to configure the Amplify library with the aws-exports.js to know which resources it can use for which category of Amplify functionality. This is usually done somewhere in your frontend code in the earliest part of the app lifecycle. For Angular, we add it in the src/main.ts:

Once this is done, we can run functionality such as "Amplify.Auth.register(userInfo)" to register a new user. We will look into more concrete examples in the following blogs.

The complete flow of adding Amplify functionality and using it can be illustrated in the following way:

Up next...

In this blog we looked at how AWS Amplify works behind the scenes. If you are considering using Amplify for real life projects, this information will help you have the confidence to make changes and fix issues. In the next blog, we will be looking at why you should consider using AWS Amplify, when to use it, when not to use it and when you should look at alternatives. See you in the next one!

The Amplify Series, Part 1: What is AWS Amplify?

Evertson Croes — Sun, 12 Dec 2021 20:26:00 +0000

The way we develop software is rapidly and increasingly changing with the world around us. One of the more exciting developments is the advent of serverless technology, which, when applied correctly, opens doors to organizational agility and speed — and thus innovation and happy users.

One of the quickest ways to get familiar with this way of working is using AWS Amplify, a set of powerful tools and features that can help you quickly and easily build cloud-powered, extensible, and scalable full-stack applications.

Amplify has selected a subset of all AWS services and default settings to help you quickly get started with building your Cloud Native application and thus provide value at a higher pace. This might seem like you are losing control over your application and that you will be limited somehow; however, with AWS Amplify, you can still override any defaults and access any AWS service if you need to.

Blog series

In this blog series I will introduce AWS Amplify, explain why you would want to use it, how it works, and give detailed examples of the several categories of functionality available out-of-the-box with AWS Amplify.

The entire series will cover the following topics:

What is AWS Amplify?
How does AWS Amplify work?
Why should you use AWS Amplify?
Developing and deploying a Cloud Native application with AWS Amplify
Uploading and retrieving images with Amplify Storage
Using the power of AI and Machine Learning with Amplify Predictions
Track app usage with Amplify Analytics
Location functionality with Amplify Geo
Chatbots with Amplify Interactions
Do everything with AWS Amplify! (Extensibility)
Low Code with Amplify Studio

We hope you will enjoy this series and extend your AWS Amplify knowledge.

What is AWS Amplify?

In this blog, we will give a high-level overview of the functionalities and tools provided by Amplify.

Functionality categories

With Amplify, we are more concerned with what we want to build instead of how it will work with AWS. Amplify offers the possibility to generate AWS services based on a set of functionality categories. At the moment of writing, these categories are:

Authentication: Fast and easy authentication and authorization out-of-the-box
API: Create and use a REST or GraphQL API as a gateway to other services in AWS, such as Lambda functions or databases
Storage: Used for storing and retrieving user-generated content on AWS such as photos, videos, or other files
Geo: Location-based functionality such as maps and location search
Hosting: Hosting your app on AWS and setting up a CI/CD pipeline
Interactions: Create chatbots for your application
PubSub: Connectivity with cloud-based message-oriented middleware
DataStore: Use on-device persistent storage to be able to use your application when offline
Functions: Create Lambda functions that are linked to an API or create CRON jobs
Analytics: Add tracking of user behavior of your apps
AI/ML Predictions: Use AI/ML to add functionality such as text translation, speech-to-text, and entity recognition in images
Push Notifications: Send messages to your customers to improve engagement
Extensibility: Leverage any other AWS service that is not covered by the categories above by using AWS CDK

As you can see, the functionality categories already cover many everyday use cases for web and mobile apps while still offering flexibility by leveraging CDK.

Tools

AWS Amplify consists of 4 tools that help you develop cloud-native applications. These are:

CLI: The Command-line interface that you can use to initialize your Amplify project and generate AWS resources
Libraries/SDK: The set of libraries used by your frontend of any kind to more easily be able to communicate with the AWS resources created with Amplify
Console: The AWS service where you can keep track of your Amplify projects and configure many settings related to the deployment and hosting of your AWS Amplify app
Amplify Studio: Amplify Studio allows you to configure your AWS resources using the console and visual modeling. Everything you change here is still compatible with the CLI, and you can even use the CLI to download the resources you designed in the studio.

CLI

With the command-line interface (CLI), you can run a few commands, you will be asked specific questions about the functionality you want to achieve, and it will generate the AWS resources based on your answers. Here is an example of such an exchange with the Amplify CLI:

In this example, we add a REST API to my project using the Amplify CLI. Depending on what functionality you want to add, you will need to answer different questions.

In the following blogs in this series, we will be using the CLI a lot and show you everything from starting a project to adding several functionalities. For now, it is important that you have a broad idea of how the CLI works.

Libraries (SDK)

We can use the Amplify libraries to connect our app to AWS resources we created using the CLI. There are libraries for all of the most popular frameworks to develop web and mobile apps:

The combination of the CLI and libraries makes it possible for your app to use the AWS resources instantly, without knowing the IP or ARN for every resource you created. Here is an example of making a REST call to an endpoint created with the AWS Amplify in JavaScript:

There are helper functions for most functionality categories covered by Amplify that help you use the AWS resources you have created via the CLI.

Console

Just like services such as API Gateway or AWS Lambda, AWS Amplify is can now also be considered a first-class citizen and can be found as a service in the AWS console. Here is an example of what it looks like when you have active projects:

The following is a list of things you can do on the Amplify console:

CI/CD Pipeline

You can set up a CI/CD pipeline via the Amplify CLI and track the progress via the Amplify Console. Here is a screenshot of what it looks like:

The default CI/CD pipeline setup has these four steps. However, it is fully configurable either in the Amplify console or by adding a .yml file in the root of your Amplify project. If the project builds and is deployed successfully, you will even see a preview of your app, and you will be provided with a link to the hosted app.

Connect Git Branch

You can connect git branches from your projects to an AWS Amplify environment you have created with the Amplify CLI. Once connected, your app can be built every time you push to that branch, and the frontend and backend environment it is related to will be deployed.

Domain management

By default, you will get a cloudfront.net URL on which your application is hosted when you first start. However, in the Amplify Console, linking a domain you have registered to a specific git branch of your project is possible. In the case shown above, every time something is merged to develop, a build is run, and once it is deployed, it is available at https://cloudthegame.com.

Configure build settings

You can change the build steps in the console as previously mentioned. You can configure custom webhooks to trigger builds for specific branches, and you can configure the settings for the Amazon Linux container that will run the build. Setting up environment variables is also possible.

View metrics

While services created with the Amplify CLI, such as API Gateway and Lambda, have their metrics, the Amplify console shows you metrics related to your hosted application. You can see metrics such as viewer requests, bytes downloaded, and errors.

Amplify Studio

The Amplify Studio allows you to achieve the same functionality you could using the CLI. The difference is that instead of answering questions in a CLI, you are clicking in the console. You will see that all functionality categories have tabs that you can configure. Once you are done configuring your backend, you can "pull" the backend to your local Amplify project and start using it in your application in the same way you would if you generated the backend using the CLI.

Here is a screenshot of the studio where we designed a data model for our pizza restaurant:

There is also a set of functionalities that is exclusive to the Amplify Studio, such as:

UI Library: You can make component UI designs in Figma and generate ReactJS component code. You can even link the components to backend logic in the studio
Data and files: You can manage your database (CMS), files, and user/groups.
Authentication: You can give users access to your Amplify studio environment without creating an AWS account. This can be useful if you have clients who want to manage the data for their application.

In short, Amplify Studio aims to be a visual development environment. While it is low-code, it is still backed by human-readable code and AWS CloudFormation, the infrastructure-as-code solution on AWS. We will talk more about CloudFormation in the next blog.

Up next...

We hope this blog post has given you a clear overview of Amplify and has gotten you excited and interested in learning more. We can achieve a lot with Amplify out-of-the-box to create a cloud-native application using the most popular Javascript and hybrid mobile frameworks and native Android and iOS. In the next blog, we will look at how AWS Amplify works to achieve all of this functionality. In the subsequent blogs, we will be using Amplify to develop and deploy a cloud-native application. See you there!