Build a Serverless App with AWS Lambda - Hands On!

We'll review all of the static HTML, CSS, and Javascript that make up our chat application so far.

For now, we'll upload some static chat data into S3 in JSON format so we have something to display.

This course uses Javascript, so let's do a quick crash course on the basics of the language.

How does Javascript execute in parallel to speed up your website, without dealing with all the nastiness of multi-threading and concurrency?

Let's dynamically modify our chat pages to include the static chat data we're vending from S3.

We'll walk through the previous lecture's challenge of adding a new message and a new conversation to our chats.

Identity and Access Management lets you secure your services and the services they have access to.

Let's give our Lambda function the permissions it needs to read our data from S3.

Let's dissect our first Lambda function, and how it works.

Learn how to create a test case for our Lambda function, and run it from within the AWS console.

Triggers are what cause your Lambda function to be executed. Let's cover the various ways in which that can work.

Let's set up the API Gateway in Proxy mode to trigger our Lambda function when an API is called from our client.

Let's modify our client-side code to hit the API Gateway and Lambda, instead of S3 directly.

We'll walk through the previous lecture's challenge to break CORS support intentionally and see what happens, and to lock down our API to only be accessible to your S3 bucket.

Let's modify our app to retrieve entire conversations using the API Gateway.

We'll walk through our solution to the previous lecture's challenge of writing test cases for failure modes.

Why use DynamoDB instead of S3? There are pros and cons to each, but DynamoDB is the clear winner for us.

Create the tables we need for chat conversations and messages in DynamoDB

Populate our DynamoDB tables with some sample chats for us to test with.

Grant our Lambda function the necessary permissions via IAM to access our DynamoDB tables instead of S3.

Modify and test our application to read chat conversations from DynamoDB instead of S3.

Modify and test our application to read the conversation list from DynamoDB instead of S3.

Modify our chat application to allow users to enter new chat messages and store them in DynamoDB where others can see them!

We'll walk through our solution to the challenge of handling invalid HTTP methods, and removing the now unnecessary access to S3 from our Lambda functions.

Why go through the trouble of breaking up our monolithic Lambda function? Let's explain.

What are resources and methods in the API Gateway, and how are they used?

What models are in the API Gateway, and how to use them.

Dissecting the request flow diagram in the API Gateway.

Let's go hands on and define our API for our chat application in the API Gateway, not in proxy mode.

Let's split up our Lambda function into individual ones for reading and writing messages.

We'll cover stages in the API Gateway and how they are used.

We'll tackle the previous lecture's challenge of removing the hardcoded "Student" user name from our Lambda functions, and providing it as an event parameter instead.

Let's walk through Cognito in the console, and set up the user pool for our chat application.

Next we need to wire things up for listing users through Lambda with an associated IAM policy and role, and through the API Gateway.

Let's add the front-end code for listing users - and dive into how to debug things when things don't work.

Let's wire up the API and front end for creating a new conversation.

Let's create a working sign up page so new users can create accounts.

Now we need to wire up a page so users can enter the authentication code they received via email, or request it to be re-sent.

Now that we can sign in and confirm users, let's actually sign them in and tie their identity into the rest of the app.

We need to reconfigure the API Gateway to use an Authorizer, and modify our input mappings to use the new authenticated user.

We have sign in and authorization on the API, and now we just need to link the two together! 

In the last lecture, we challenged you to fix the problem of starting chats with yourself, and to ensure you can't see chats that you're not involved in. Let's look at our solution.

Let's see how Stage Variables can let us maintain separate databases, or resources in general, between different stages so they don't pollute each other.

Let's talk about how CloudFront, AWS's content delivery network, works and why it's important.

Let's walk through setting up CloudFront to accelerate the delivery of our static resources in S3.

We'll tour the various monitoring available in AWS for our application, and practice setting up an alarm.

Finally, let's walk through how you would go about associating your own custom domain name with this application. We'll also show you how to associate a custom domain name with your API layer, if that's something you want to expose more widely.

There's so much more learn about AWS! Here are some pointers for continuing your exploration.