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
In this lesson I want to show you the authentication process just a little bit more in depth. First I want to start by expanding this and setting Network and then let's login. Once I click Submit I'm going to see the actual calls to, let's scroll back up. These are the calls to cognito where it's actually doing authentication for us.
So this is handling the authentication process password verifyer Okay. What's interesting is now once that was made in the header here you can see we have this authorization token. This comes from our java script and I'm going to jump into exactly where that pulls from. So in this off token promise we call the Get JWT token for the Get ID token.
Now when you're working on this yourself it's usually helpful to be able to understand what's happening. Let's copy this. We're going to head into API gateway. We're going to Authorizers and you might remember this little test to link from before. Click on Test and let's paste this in. What this will do is it's going to show us what claims are going to be returned for this token.
It let's us know that the token is correct so if our token is good and something still isn't quite working, we're not getting the claims that we expect you'll know that it's something to do with your mapping or maybe something in your code so click on Test and we're going to see claims here cognito user name, we have our sub our token ID, our email.
We can ensure we've verified our email address. So all of this is going to help when debugging. I want to show you a few changes let's remove some of the characters here so you can actually see, I'm removing some I'm just going to do that right. And click Test, unaurthorized request. So you can have the authorizers automatically test that your token is working.
Your token's going to expire, if I paste it back in it doesn't have a long shelf life So see expiration is just an hour after its issued, okay. So it's not a long shelf life. If that token expires on the front end it's going to take you back to the login because you need to re-authenticate. So it's something to think about when dealing the authentication process.
What happens is the front end makes a call, the front end makes a call to your identity pool and it tries to authenticate the user based on your email and password and then it calls the success or failure handlers and in this case if we look up here where we're actually kicking off our login you can see that on success we set the app state to logged in.
We clear out the user name and password so that they don't stay in the browser and if it's marked as not yet confirmed it sets it to needs update. So we attempt to login with the cognito API. Once we get that token back we then can pass that around we save it up here in the application config settings and then we pass that around as needed so you see here when we kick off this off token promise we set the token here when we call our additional functionality for example, our Save when we call that we need to pass on our token so we have it saved in this token variable and then we can just pass it in to all of these different functions that are going to pass this in in the header.
So on the UI every API call we make needs this authorization if it doesn't have it, it's not going to work. Let's prove that. Let's comment this out. Save this and reload this page. Okay notice this is trying to report and error. If we look on the console it's going to tell us that we're basically not allowed to access this so because the header isn't there we can't make this call.
We put it back, you can see there's our list. If you took off the authorization on your resources, so you can disable this you can set this to NONE here but then you'd lose out on the functionality of using the cognito user pools. So it's just something to be aware of kinda understanding better how those things connect together.
Alright in the next lesson let's take our front end code, get it deployed and see if it all works when everything is deployed where it needs to be. So if you're ready 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.