For years, web development has continued to evolve alongside programming languages, tooling, and frameworks. It started out with static web sites before moving on to dynamic sites that were rendered on the server. Over time, as JavaScript frameworks gained functionality and popularity, there was a shift towards putting more of the logic into the front end, and using the back-end as a supporting API.
Throughout all the changes in web development over the years, the server has been a constant. Regardless of the languages, tools, and frameworks used, there’s always a server running the code. And that’s something that hasn’t changed. What has changed is that cloud providers now make it easy for software engineers to focus on writing their code, without having to focus on the underlying server.
In this course, you'll build a serverless web application using Python 3.6. You'll use Lambda, API Gateway, S3, DynamoDB, and Cognito to create a multi-user to-do list application based on Vue.js.
Note: The Apple M1 chip isn't compatible with this course currently. We recommend using a different device.
Learning Objectives
- Outline the architecture of a serverless web application
- Set up the AWS services required for the app
- Create and deploy an API using Python 3.6
- Explain the value of creating unit tests
- Use a Cognito User Pool within your app
Intended Audience
- Developers
- DevOps Engineers
- Site Reliability Engineers
Prerequisites
- Familiar with AWS
- Development experience
- Familiar with the CLI
Resources
Welcome back. In this lesson, we're going to set up the services that we're going to use for this project. We're going to set up Cognito, DynamoDB, we're going to get an IAM user, we're going to set up an S3 bucket, and we're going to have all of this ready so that when it comes time to actually deploying our Lambda functions, that all of the underlying infrastructure that it needs will be ready.
Let's start with DynamoDB. Okay, we have nothing here. We're going to call this "Todo List. " We're going to use two keys. We're going to use a userID, and we're going to add a sort key so that we can have a composite key. We'll call this "todoid. " The way this is going to work is, this will allow us to look up the to-do list items by user, because that's our primary partition key, so we can look up all of their items.
Or, we could look up by user and to-do list ID. That way, we can zero in on a particular record. This is going to give us some flexibility in how we are going to fetch this data, because we can pull all the records for a user or just the one to-do list item for a given user. Okay, so that's all that we need.
We'll use default indexes, and let's create this. This is going to take a little while, so let's not wait around while that's happening. Let's jump over into a new tab, and let's set up our Cognito user pool. This user pool is going to allow us to have our canonical source for our users for this application.
Let's click on Create. We'll give it a name. Todo User Pool, and we can just click Review defaults. Most of the defaults are going to be good. We're going to change this, so let's click on that, and instead of username, let's select email address, and we'll make sure that allow email address is set here.
Okay, everything else is good. Now let's go to app clients. Let's add an app client. Okay. I'm going to uncheck this Generate client secret, because we're using JavaScript to access this. You're not gonna use a client secret with JavaScript because it would be publicly exposed and there would be really little point in having a secret if you share it with everybody, so, uncheck that and create.
Okay, great. Now let's go to Review. Everything else looks great. Minimum password: You can change this in a real application for your users. Maybe you don't want to go with the uppercase, lowercase, special, and numbers. Maybe you want to do something different. That's up to you. You might also want to enable multi-factor authentication.
Again, that'll be up to you. But for now, this looks pretty good, so let's create that. Okay. This is created. . . We're going to be using the pool ID and the app client ID later on, but for now, let's just leave this here, and we'll move on to creating our IAM user. This is going to be the user that deploys the API gateway and Lambda functions, so this user needs at least those permissions.
What we'll do is, we're going to give them admin permissions. It's going to be a little bit easier for the demonstration. That's not best practice. You're going to want to lock that down so that they can only do what they need to in a real application. Let's go to Users, and we'll add a user. We'll say "todo_developer."
We'll make sure we check Programmatic access because we're going to be using the CLI with this user, and let's select Next, and this is where we can set the group. Let's create a new group, and this group will just be "todo- serverless," and I'm going to give them admin access. Again, not best practice, but for a demo, it makes it really easy to make sure everything's working.
Okay. Click Next. Everything looks good. Create. Okay. Let's do two things. We'll download the CSV. This is where the credentials will be stored. That way, we have them locally, and we're going to click Show here. Now, this is a demo again. I've mentioned that before, but it's important to mention again because you don't want to show your secret keys to just anyone.
That's what I'm doing here. I'm going to have to revoke this key before I publish this course, or else just anyone would have admin access to my AWS account. It's very important that you keep these things locked down and that you make sure that they don't leak. You don't want them anywhere in code or anywhere that they're published to GitHub or anything like that, so it's very important that you keep these things as secure as possible.
Okay, I'm going to leave this tab open. It'll just make it a little easier for me to copy and paste it right here from the browser when it comes time to set these values in the credentials file. There's one more thing that we're going to need, and that's an S3 bucket for our front-end code when the time comes to actually publish the JavaScript, HTML, and CSS.
Let's click on S3 and let's create a new bucket, and we'll call this todo- serverless- ca. Okay. This looks good. Let's click Next. We'll leave these as-is. Okay, so what we're going to do is, let's set this to grant public read access to this bucket. It's worth noting that we're only doing this because this is going to be an actual bucket holding our web assets.
You would never want to do this if you're going to store any data that is confidential. We've seen a lot of leaks in the news recently where people have put customer data in a publicly accessible bucket. Don't do this. This is awful. We're going to do this because it's just HTML, CSS, and JavaScript. It's going to be public information anyway, so it's going to be okay, so let's click grant public read access.
Everyone in the world has access to this. Amazon has recognized that this has become a problem. People are putting private data in public buckets, so they're trying to make sure that you know that this is going to be public. Okay, let's click Next, and that looks good, so let's create this bucket. Okay.
Now with this done, we have the services that we need sitting there ready. We haven't touched API gateway or Lambda and that's because we're going to be using the command line interface for that, so that's why we haven't done that here, but now we have everything that we need to actually get this application deployed.
Okay, with this done, let's take a look at the code in the next lesson so that you're familiar with it before we actually deploy it. So, if you're ready to take a look at some code, then I'll see you in the next lesson.
Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.