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.
- 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
- DevOps Engineers
- Site Reliability Engineers
- Familiar with AWS
- Development experience
- Familiar with the CLI
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, 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.
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.
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.