 Hi everyone, my name is Kyle Knapp and I'm a software developer at Amazon Web Services where I primarily focus on developing Python client-side tooling such as AWS CLI, AWS SDK for Python, also known as Bota 3, and a Python micro framework for developing serverless applications known as Chalice. And today what I'm going to talk to you about is how you can go about writing server-side applications using Chalice. To start what I want to do is go over an outline of what I'm going to talk about. First I'm going to give an introduction into serverless applications, mainly talk about what they are, why you care about them. I'll give an introduction to Chalice, so getting started with Chalice and some of the core concepts. And then I'm going to go ahead and actually have a sample application show you how you can build it from the ground up using Chalice features. So before I talk about what exactly a serverless application is, let me talk about why you care about it and the benefits of serverless applications. To start, serverless applications mean you're not managing or provisioning servers, so that's less of a DevOps load for you. Next, you're only paying for the execution runtime for your code, so if you're managing your own server, you're still paying for the server to be up and running, but even if there's no code running, you're still paying that cost. And finally, you get scalability. So in terms of serverless applications, they're usually hosted by a service and it handles all of the scaling for you, so you don't have to worry about load balancing to meet the request needs of your scene for your serverless application. So now let me talk about what exactly a serverless application is. So here we have just a client and a server, and on the server, we just have a simple hello world function running. When the client sends a request to the server, it will go ahead and run the code and reply back with hello world. So with a serverless application, this all completely goes away, and it gets replaced by a service such as AWS Lambda. AWS Lambda is a service for hosting your serverless applications, and what happens here is you have a bunch of code, you upload it to AWS Lambda, and AWS Lambda will store that code for you so that when you make a request to AWS Lambda, it will go ahead and execute that code and return the response hello world back for you. So the key part here is you don't own the server, you're not managing it or anything. It's all handled by AWS Lambda, and it will handle all the scaling for you as well. So now with that brief introduction of what serverless applications are, let me talk about Chalice. So Chalice is an open source Python micro framework for managing serverless applications on AWS Lambda, and integrating those serverless applications with other resources in your AWS cloud. So to get a better idea of what Chalice can do, let's go over a common use case you may use Chalice for, and that comes with REST APIs. So with a typical REST API, you send a resourceful request, so you're sending a git to the root path of your API, and you'll get a HTTP response back, or maybe you send a git request to the resources component, and you get all the resources back from the REST API, or maybe you want to change the method, maybe you want to put a specific resource into your API and apply back with the HTTP response. So the way that it takes AWS Lambda, it uses as the back end your core functionality for your REST API, and another server is called Amazon API Gateway, which is essentially the front door for your serverless application. It's handling the HTTP requests, sending the HTTP responses, handling the throttling, and any authentication for you. So now if you send an HTTP request here, it'll get sent to Amazon API Gateway. Amazon API Gateway will then invoke your Lambda function, or run your code, and return a response back to Amazon API Gateway, giving you an HTTP response back. Okay, so now if you kind of take a look at the simplified version of how it's set up, it looks pretty simple. It's just a two-way directional relationship, but in reality, if you were to go ahead and start this from scratch, it's a little more complicated than that. In reality, you need to worry about setting up an IAM role for your Lambda function, so you know what permissions you have. You need to actually take your code, dependency, zip it up, and set it to create a function. You have to create a squagger document to create your REST API for Amazon API Gateway, and link it all together by adding permissions for Amazon API Gateway to go ahead and invoke it and create a deployment so you can hit it with an HTTP request. The nice part about Chalice, though, is that you don't really have to worry about this. If you were to do this by hand, you'd have to go through the console. You'd have to use an SDK or a cloud formation template, but Chalice handles this all for you, allowing you to focus on the actual Python aspect of your application. So what I have here is a video of how you can kind of get started with Chalice. The Wi-Fi's been a little spotty, so I wasn't going to do a live demo, but in order to save some time, in case things don't go as planned, I have this video being ran. So first, you need to pip install Chalice by using pip install-pre. Right now, Chalice is 1.0 beta, so you need to use a free flag. And once you do that, you can go ahead and run Chalice new project, and that'll get you started with a new, brand new Chalice project application. It'll create a new directory, and inside this directory, you'll see two files. There's an app.py in requirements.text. The requirements.text initially is empty to start, and that is where you specify all the dependencies for your Chalice application. So what happens with Chalice is that if you specify dependency in your requirements.text, it'll go ahead and download the dependency when setting your deployment package to Lambda. So the second file, the app.py file, is where all your core functionality exists. And if I open it up right here, you'll notice it's actually very similar to if you're familiar with Flask, where you create an app object, and you go ahead and specify routes for that app. So right here, we're registering a root route, so that if a HTTP request is sent to it, that's a git. The index function would get ran and return hello world. So let's go ahead and actually quickly just deploy this app using Chalice. So as this Chalice app is getting deployed, one thing I want to mention is, while this application is just sending hello world, this is a production-ready application. You can send as many requests as you want, and the AWS Lambda will scale it up for you and be able to handle any incoming requests. So once it's going to be done deploying, it will go ahead, and there's one more thing we're going to need in order to start hitting the API. And that is a Python library called htbpy. That's pretty much a command line tool for making HTTP requests from the command line. So if I go ahead and actually run Chalice URL, I can see what my API URL is again. Go ahead and copy it and send a git request to my API. And you can see it returns back hello world. Cool. So now what I can do is if I want to add more routes to my application, I can go into my app.py file and go ahead and add new routes. So for example, I'm going to go ahead and add the foo route to this application so that if a git request is made to foo, I will go ahead and run the foo function that will return foo bar. So now once I have that updated, I can go ahead and run chalice deploy again. And I'll update my Lambda function. And I should be ready to go in and actually start using this new update to my API. So now I'm going to get my URL real quick because I don't have it memorized. And I go ahead and paste that and add the foo component to my path. And from there, what I'll get is the expected response I want back. So it should return foo bar, which it does. So the two things I really hope you guys got out of this demonstration was how quickly you hit the ground running using a chalice application to start using just chalice new project and chalice deploy. And also the fact that chalice is handing all of the AWS resource set up for you. So you don't actually have to worry about AWS. You just have to focus on the Python-specific logic of your application. So now what I want to do is go to some of the key components of a chalice application. And by going over the sample app on the right. So what I have here to start is a app object that I create, and I register a bunch of routes to it. So let's take some sample HTTP requests and see how the app reacts. So here we're just sending a get request to the root path. And what that will happen is we'll match up with this route, and therefore when AWS Lambda gets invoked, it will run the index function. Once it runs, it will return back Hello World to the end user, and Amazon API Gateway will forward an HTTP response back saying Hello World. So now let's take a get to the resource Hello. This will match up with this route here and run the Hello Europe Python function. And once it's run, it will return Hello Europe Python as a HTTP response back. OK. So now let's actually look at something different now. So with this request right here, you'll notice that the exact path doesn't actually match up with any of the literals here in the app.py file. What will happen is it actually matches up with this route. And that's because if you provide a curly bracket in your path, it means it's a variable. So you can provide any value you want. In our case, we're just providing Kyle as a variable. So as a result, Lambda will run the Hello name function returning back using the name provided. And this name parameter is passed in using the variable in the path. And as a result, the value of name will be Kyle, and go ahead and return Hello Kyle back to the end user's HTTP response. So the final one I want to talk about is the post. So with the post, what happens? You'll notice that it uses the resource Hello, but it doesn't use the second from the top function. That's because it's a post. And the route registered only allows for a post if used in the method's keyword arc. So by default, if you don't specify any methods, it will only allow for gets. So as a result, Amazon API Gateway will invoke this Lambda function with the post function involved. And if you're looking into the post function, you'll notice that it uses the app.currentRequest. That refers to the HTTP request that triggered the Lambda function. And you can get properties of other requests, such as the JSON body. So for example, you will have the value JSON body when you're actually invoking your function. So now that when you return, you'll notice that the JSON body matches up with the actual request. Cool. So that was just a brief introduction, Chalice. Let's talk about the main points I covered. One, in order to start a new Chalice project, you just need to run the Chalice new project command. It lets you hit the Regan running and immediately deploy that. Chalice deploy, if you make any changes to your application, all you need to do is run Chalice deploy. And you can immediately start using it and sending HTTP requests to it. App.Route, that allows you to run specific functions based off the HTTP request path or method that you sent. And finally, there is the current request property, which allows you to access the current request that triggered your function. So let's talk about the sample application part. This is the meaty part of the talk. In my sample application, what I did was I created a trivia app. So here is a video of me running my trivia app. If you're interested, you can go to that URL. It's a public S3 object or a bucket. And I'm going to go ahead and kind of demo this from the video. So here what happens is that the application will ask my REST API a specific question. So it'll give me the question and a list of possible answers to use. And what will happen now is let's try to answer this question. Hopefully, everyone knows where they currently are right now. In case you don't know, we're in Rimini, Italy. So let's go ahead and select that answer. And then there's a separate API request that will now let you post the answer to figure out if you got it right. So of course, by posting the answer Rimini, Italy, we got that right. And we can go ahead and query for another answer on our REST API. So now here's the second question, asking about spaces, how many should be used for indentation. Let's say we're completely new in Python and we put none use tabs, which is obviously wrong. So the chalice app will send a request and it will tell you that you're wrong and you get the next question. So let's just say we've been answering a lot of questions. We want to keep track of our score, where we are. So we have this additional ability to go ahead and sign up as a user and be able to log in and keep track of our score over time. So I'm going to go ahead and add this as my username being Kyle and then give it a password. And then from there, I can go ahead and log in. So once I log in, what that will do is take me back to the original question and I can start answering. So for this first question, let's say I forgot that it's 2017 and I thought it was 2016, I put Bill Bowdown, which is obviously wrong. Now let's actually get this answer correct. And once we submit four here, we should be able to go ahead and get the next question and see what our current score is. You can see that total correct is one, total answer is two. I can now say, let's say I want to take a break and go ahead and log out and resume later. So if I go ahead and log out, it will return to me back to the original question and I can go ahead and log in again. And that should take me back to where I left off was that third question about the Zen of Python. So that's the gist of my application. What I want to do now is actually talk about how you go about writing this application with Chalice. So there's three steps in writing this application. One, you have to worry about the question to answer API, that whole idea of getting a question and then posting that answer in order to determine if you're right or wrong. There's the web application portion, so specifically the browser logic to make sure that you can work in the browser. And then there's the third step, which is authentication users. So being able to handle registration, login, and being able to track user score. So in order to show the rest, the git answer in a post-answer API, let me go over this new video in which what I'll do is, I'll show you the initial branch of, right now I have the master branch that has all the prod stuff on it. I am using this initial API branch that just has the git and post. There's additional APIs that I'll need later on. But to kind of show you Chalice deployment, what I'm gonna do is deploy this branch to AWS Lambda and API Gateway. And I wanna make you understand that in this command I'm running, I am running it with a dash dash stage argument. So the purpose of dash dash stage is that it'll allow you to combine your resource into specific stage groups. So right now I have a bunch of resources running my prod application. So if you went to the browser page, it's hitting all my prod resources. If I'm gonna go ahead and deploy, deploy new resources, deploy new logic, I don't wanna be deploying straight to prod, right? I wanna be deploying to some other stage that has all the resources isolated. So that is what I'm doing here. And then once I feel comfortable, I can go ahead and deploy it to prod. So in order to hammer that point home, all I have to do is run Chalice URL with a stage URL to show that the actual URI that I get back is completely different from what the dev stage is. So now let's actually get into the question and answer a part of the API. So if I want to actually go ahead and get a question, I go ahead and copy this URL in and I add the path components questions and question ID. So in terms of how we do questions, that you have to provide a question ID. They start at one increment by one each time. So by running a get on this URL, you will get the first question for the tribute application. So when we run a get on that, you'll see that it returns back that EuroPython where it's being held and the possible answers they can use. It didn't reply to an answer back, so you're gonna have to go ahead and post this answer. We allow for a post the same URI. And then what we're gonna do is include a JSON body in this post for our server to be able to figure out what the correct answer is. So we provide the answer key and the actual answer. And once we actually go ahead and post this, it'll tell us if we're correct or not, in which we were work correct. In the case where we submit a wrong answer, it'll do a similar thing. But so let's say I put down Bilbao Spain instead for this. And what will happen instead, it'll just tell you, all right, the correct answer is actually Remini, but the, and you got your answer wrong. So let's go ahead, now that you have an idea of how the REST API looks, let's actually go talk about how you'd go about doing this. So let's imagine we have our get question API. We have a question table that has all of our questions. In order to set up a REST API for this, all we need to do is stick a Chalice application in between the two, so that if you send a get request, it will be forwarded by Amazon API Gateway to Avis Lambda, which we'll read from the question table, and return the information back to the user's HTTP response. So now, if they provide a question that doesn't exist, that would be the same logic, but Lambda will realize it's not on the table until Amazon API Gateway to give the user a 4.4 at the very end. So here is some sample code on how you actually implement it. Don't worry about trying to read through it all right now. I'm gonna step through it one by one, so make sure you pay attention. So to start, I just import Chalice here. The second thing I import is a ChaliceLib.question. So this is not a dependency of Chalice. It's actually a built-in functionality. So if you want your application to grow outside of an app.pf.wifile, like you want more than one file involved, you can use something called a ChaliceLib, which what it'll do is you can create a new ChaliceLib directory in your Chalice app, allowing you to put new modules. Like I added a question spy module into my ChaliceLib directory. And this is a lot different than requirements.txt because requirements.txt is mainly for third-party package dependency. So stuff that you didn't write, but you just want to take a dependency on. Afterwards, I go ahead and create my app object. And then I register my route and a handler for it. It accepts a question ID because question ID is a variable in the URI. And now all we have to do is create a questions table called getQuestion. This return none if the question doesn't exist or a name tuple of information about the question. So if the question doesn't exist, we're gonna go ahead and raise this Chalice.notFoundError. So Chalice has a bunch of built-in exceptions that allows you to raise it in your code and Amazon API gateway will propagate the specific status code back to the end user. So by raising a Chalice.notFoundError, you will raise a 404 to the end user. So now after all that's been gone through, we can go ahead and return the question ID if it was found. So the post side of it is very similar to the get. All you have to do is in ABS Lambda, once you get the question back, is determine if the provided answer is correct. And if it is, go ahead and return true to the end user. So here again is the code required to do this. Don't worry about reading this all through right now. I'm gonna step through it again. So to register the route to start, we use the same path as before, but instead we specify a post. The last route we registered was only a get. So now we go ahead and create our function handle in which we accept question D as a parameter because it's a variable in the path. And then from there, the very first thing before we do any core logic is to make sure that the answer is actually in the JSON body. And if it isn't, we raise another built-in Chalice exception, which is the bad request error. This will raise a 400 error to the end user in terms of an HTTP response. And then from there, what we can do is do some of the more core logic and figure out what they provided and get the actual question. Make sure that the provided answer is a list of possible answers. If it's not, let's go ahead and raise another bad request error, another 400 and tell them you need to provide an actual answer, the list of possible answers. Once all those checks have been complete, what we go ahead and do is return if they're correct, what was a provided answer, and the actual correct answer. So that was the question and answer part of the API. Let's talk about what we kind of learned in this section. First, we talked about Chalice stash-stage, so the idea of being able to group your resources into different stages so you don't interfere or deploy over your existing resources. So if you wanted to experiment with a dev stage, you can keep your prod stage running and not have to worry about deploying over what you had previously deployed. We talked about Chalice exception handling, so raising a built-in Chalice exception to go ahead and propagate a specific status code you want back to the user. And we also talked about Chalice Libs. So if you wanna outgrow your app.py file, you can go ahead and create a Chalice Lib directory and create your own modules inside of that. So now that we talked about the question and answer API, let's talk about the web application portion of it. So for the web application, there's two things we're gonna have to worry about. There's, we're gonna have to add ability for cores and we're gonna also have to get an SDK to be able to interact with our API in the browser. So with cores, right now what I've been doing is just making API requests with my laptop to my REST API. I don't really have to worry about cores. But the minute I put a browser in there, we have to worry about data security in terms of making cross-domain requests. And to do that, we have to abide by cores. And here's an example for a simple get request. What happens here is that when we send a get request, it'll send the same response back, but we also include this header right here. The access control allow origin header, which specifies what origins are allowed to read this resource. In our case, we just provided a star, meaning any resource can. If the request gets a little more complicated, maybe it's a put or has some extra headers, the browser will also send some preflight request in terms of an options HTTP method. And in order to do that, it'll determine what permissions it has to send in this request. So specifically, the server will apply back with what headers you can reuse in your request, what methods you can use in sending it, and also what origins are allowed to access this resource. In order to enable this in a Chalice application, it's quite simple. You just add cores equals true. That'll give you all the default values. It'll get you a star for the allow origin. It'll give you a preset of headers. And any methods that have been labeled as cores will also add that to the enable methods, allow methods for the cores headers. If you want anything more specific, you can go ahead and run it with cores config instead of a Boolean, and you can get specific values that way as well. So now what I wanna do is talk about generating SDK. So the front end application I have is already in JavaScript. Don't worry, I'm not gonna show you very, very much JavaScript. This is a Python conference. I'm way more confident with my Python abilities, so I'm gonna spare you guys of that. But with the Chalice Generate SDK, what allows you to do is generate a JavaScript-based SDK to interact with your API. So here is an example of how you go about doing it. So all you need to do is just run Chalice Generate SDK and specify a directory. And what's gonna happen here is that Chalice will make an API request to Amazon API Gateway, and Amazon API Gateway will go ahead and generate your JavaScript SDK for you. Chalice will then download it and unzip it into directory that you specified. So now if I go ahead and CD into this directory, you can see the different files that have available to me. And you can see that I have an API Gateway client, JS file, and under here you can see some client code. Let's look at the more specific things related to our application. So for example here, we have our invoke URL. You can see this is exactly the same as our dev stage. So this is the URL we're gonna be hitting in the end. Then if I skip along a little bit to the later on in the file, you can also see some of the methods, so some of the routes. So you can see here, this is just the questions. So this is the get question part of the API. This allows me to get my information about a question. So that's it in terms of how much JavaScript I'm gonna show you, but it just gives you an idea of how you can have easy access to your API from a front-end application. So continuing on, let's go ahead and talk about the last piece that we need in order to complete this application, which is authorization in users. So in terms of authorization in users, the one thing, if you remember from the sample application, there was the ability to log in, there was the ability to register yourself and be able to keep track of your score and where you've been. So Chela's has a bunch of different authorization options available to you. There's of course none, which we've been using the entire time, we don't have to be authorized to use our APIs. There is IAM Authorizer, which is using AWS Crenshut credentials and Amazon SIGV4 signing to give authorization. There's Cognito User Pool Authorizer, which is using Amazon Cognito, which is a managed service for managing users and user pools and handling credentials and login and registration and whatnot. And finally, there's ability to define your own authorizers using the decorator app.authorizer. So in your Chela's code, you can go ahead and actually implement all the logic that you need for your authorizer and then link that up with your REST API handlers. For this application, I'm going to be using the Cognito User Pool Authorizer, mainly because Amazon Cognito User Pool gives you a lot of functionality right out of the box. So mainly, it's to be able to manage users, so it's to be able to manage all the user data there and handle login and registration all for you. It provides SDKs for user registration login, so my front-end application is just a simple function called to get my credentials or to register a new user, and also provides AWS Lambda triggers. So while it provides an out-of-box solution, if I want to customize it all, I can create Lambda functions that will customize the process in terms of how a user signs in or registers himself. So in order to talk about how an authenticated user answer would be, let's talk about the anonymous one first. So here's the setup for the anonymous one. If we want to actually add an authenticated answer API, we go ahead and add the user component here. And in adding the user component, we need two more resources, one being a user table. We also need Amazon Cognito. So in terms of the workflow, in order to actually keep track of the user's answers, we need to do the following. First, the client will have to make a request to Amazon Cognito using their username and password to authenticate themselves. Once they've been authenticated with Amazon Cognito, they go ahead and return a JWT token back to be used in subsequent requests. And from there, you can go ahead and post your answer. But notice that there's an authorization header included that matches the exact same JWT token. And Amazon API Gateway will then check to make sure that they're authorized. And go ahead and invoke the AWS Lambda function. AWS Lambda will make sure that what their answer was was correct. And based off the result, we'll go ahead and record that in our user table. And finally, return that HTTP response back to the end user. So to actually implement this, here is sample code on how you do it. I'm going to step through this one by one again, so follow on. Here, what I have is the poolarn. So the Amazon Cognito user pool, I set this up prior to any Chalice deployments. And the poolarn is essentially the identifier for this pool. And from there, what I do is create a Cognito user pool authorizer. So I provide my poolarn to that to have an authorizer that I can then take my route and assign it as my authorizer. So any request going through this route has to have Cognito user pool authentication in order for it to pass through. So now from there, what we'll go ahead and do is create a function. And go ahead and run to answer question function. If you remember from before, answer question comes from just anonymous post questions question ID route. Once we have the answer data, we need to actually figure out who the user was to just answer that question. And in order to get that, what we can do is go ahead and run this helper function called get authenticated username, which uses a property on the current request object, which is the context. The context provides information about what exactly triggered my Lambda function and just information about it. And if I open this up, you see I get a big JSON dictionary. I actually shortened this dictionary because if I didn't, it'll fill up the entire page and it didn't have any room. So I shortened it just for the specifics that we want. And specifically what we want is the Cognito username out of it. In this case, the username was my username. So another point I want to make out to you is that ideally, if you're keeping these in a database, you probably want to be using the subtoken. This is a uniquely generated ID by Amazon Cognito. So if you're trying to add these users to a user pool, you probably want to use that as a primary key. But I'm just using Cognito username for simplicity and reading for this talk. So now I go ahead and create my user table. I update my user score and return the answer data, which came from the answer question. So now that we have log in all handled and keeping track of user score, the one thing we haven't covered is how do we handle registration of users? So like I said before, Amazon Cognito provides to you a out-of-the-box solution, but you may want to customize it. In my case, I actually wanted to customize it. Specifically, in terms of registering new user, usually you sign up and then you have to do a confirmation of this. The user has to then confirm themselves. I wasn't particularly interested in doing a confirmation, so I wanted to be able to disable that. A second thing I wanted was that immediately after a user registered, I wanted to keep track of them in my DynamoDB database. I did not want to only have access to users that have just answered a question, because that's the only way I'd be able to track it by adding them when I invoke the lambda function. So in order to do this, I add two more lambda functions, one lambda function for auto-confirming functions, auto-confirming the users, and another lambda function for actually adding users. And the way it works now is once you register, you send a username and password to Amazon Cognito, and Amazon Cognito will start the registration process. And these lambda functions are hooked up to specific points in the registration process, so that Amazon Cognito will then invoke the lambda function on a specific point. So at the pre-signup trigger, we'll go ahead and invoke our auto-confirm function, in which case the lambda function will respond to Amazon Cognito to go ahead and say, you can go ahead and auto-confirm this user. After they've been signed up and confirmed, there is another trigger called the post-confirmation trigger. And with the post-confirmation trigger, what we'll do is have the Amazon lambda function go ahead and actually add the user to our table. It'll turn back a response, and Amazon Cognito will tell the user, you're all signed up, you're good to go. So the auto-confirm function. It's not very difficult to do this. All you have to do is, in your app.py file, go ahead and add this function right here. So this is a little bit different than you've been seeing previously. We've been using routes as a decorator. This time, we're actually using the lambda function decorator. So what that means is a standalone lambda function. So it's not connected to any API gateway, so you can't actually make a REST API request to it. And it's also isolated from your API lambda all the logic that's handling your routes. So this function now accepts two arguments. There is the vent in context. The vent is usually a dictionary that has all the parameters that triggered this lambda function. And the context has information about how the lambda function got triggered. If I actually look at the vent here, you can see the different information I have available to myself for this presignup event. And specifically, what I'm interested in is telling this auto-confirm user value of false and setting it to true. And after that, I'll go ahead and return the vent, this entire thing, telling Amazon Cognito to skip the confirm signup step. So in order to add a user now, this is not too difficult either. All you have to do is add another lambda function here. And like I said, like I did in the last one, the lambda function is a standalone lambda function because it's using the lambda function decorator. So it's not connected to Amazon API gateway. And the event that it takes in is this event here. And out of this event, I can get information, such as the username, which will allow me to go ahead and add the user to the user table. I can go ahead and return the entire event to Amazon Cognito. And then that's all it takes for the entire registration process to happen. One thing I also want to mention before is that after these lambda function deployed, I have to go ahead and add these as triggers to my existing user pool. It's a one-time setup thing, but I'm using Chalice mainly here, so I can handle the deployments and updates of my lambda functions and my Chalice application because it makes it very easy for me to update it. So going back to that line, let's talk about what we learned in a section. We talked about how to use Amazon Cognito to give authorization for your Chalice application. We talked about app.currentrequest.context, so being able to get information about your lambda function and how it got invoked. And then finally, we talked about the app.lambdafunction decorator, so being able to set up a standalone lambda function that is not connected to Amazon API gateway and just runs by itself. So given the time constraints, there's some other Chalice features I really wish we got to talk about, but unfortunately, it was not able to. One feature being the app.schedule decorator. So this is like the lambda function decorator, but it's cool because you can essentially have cron jobs running for your serverless application. So every X minutes, every X hours, or a specific day of the week, you can have a lambda function run. So that's very convenient. Another one is dependency management. So if you remember before in the intro demo, I talked about requirements.txt and how it downloads all the dependencies you need for you. While that's pretty straightforward, but when it comes to C extensions, it gets kind of complicated because with AWS Lambda, its underlying operating system it's running on is Amazon Linux. So if you send up a compiled version of the C extension that isn't compatible with Amazon Linux, you're gonna have a lot of problems when you're Amazon and you're AWS Lambda function. The cool part what Chalice will do though is it will actually download wheels for you that are compatible for Amazon Linux, unzip it into your deployment package and go ahead and allow you to run that in the lambda. So for example, if you're doing your deployments from a window machine and you had a dependency on NumPy, for example, it'll go ahead and download those wheels for you that are compatible for Amazon Linux and go ahead and include that deployment package so you can have NumPy run in your Lambda function. It doesn't matter in the operating system. So last thing I wanna talk about, additional Chalice feature is the AWS IAM policy generation. Which what it allows you to do is if you remember from the very first, one of the first slides where we're talking about the setting it up from scratch about the IAM policy. So Lambda needs a bunch of permissions in terms of if you're gonna access other AWS resources. What Chalice will do is scan through your source code, determine all the operations you're using, all the AWS resources you're using and actually generate that IAM policy for you so you don't actually have to worry about that part of the Lambda deployment part. So now let's start wrapping this up. The one thing I really hope you guys got out of this talk was the benefits of using Chalice. From the beginning it showed how it allows for easy and fast-paced app development. So from Chalice's new project, you can get quickly started and deploy that application and quickly iterate on top of it. There's not a lot of boilerplate code you need to worry about in deploying Chalice application. I think in the end my app.py file for this entire application was less than 100 lines of code. So that was really nice. Another point is it handles all the AWS resource manager for you. So it provides a nice abstraction on top of your, top of all the AWS Lambda and API gateway stuff so you don't actually have to worry about that. It'll handle it all for you. So you can just focus on the Python specific aspect of your code. And finally it produces production ready applications. Production ready being it's being ran on AWS Lambda and therefore it's handling all the scaling for you and all the infrastructure management. So you can go ahead and deploy it, just leave it there and not have to worry about it or worry about any of the DevOps related to it. Okay, so the final thing I wanna mention is that we released Chalice 1.0 beta last week. So what that means is that while it's still developer preview we're getting very close to actually going GA with this and having that 1.0 release. So between now and when we actually do 1.0 it's only gonna be small enhancements based off user feedback and trying to polish up the final interface. So I really hope this talk motivated you guys to all try out Chalice, try writing some serverless applications. And if you have any feedback, come find me or there's another dev here, James from the Chalice team or you can also post an issue on GitHub. And any feedback we can get between now when we go GA is very valuable. So we'd be grateful for it. So one thing I wanna say is here's some related links. Here's a Chalice repository, Chalice documentation and also all the code I use for my Chalice trivia app you can find it here. I need to fill it out to read me a little bit so if you're trying to deploy it initially you might have a little bit of issues but you can at least get a gist of how I actually went about writing this application. And you can follow me at Twitter at VCalNap for any updates related to this talk. And also if you wanna talk about AWS, Chalice or any of the libraries that I work on please come find me or my team member team member later this week I'll be here the entire conference. So if we have time for questions, we can do it after but thanks everyone for coming and listening. We do have time for a few questions. So let's get started. Hi, hello, is Chalice providing, good talk by the way. Yeah thanks. Is Chalice providing any way to manage resources like S3 buckets or databases or anything else? Not currently, the closest thing you could do is it provides the ability to have CloudFormation templates where you can have an S3 bucket there but one feature I really wanna add is some of the major resources like S3, DynamoDB something you'll be using a lot in your application and being able to manage it but that's something on the roadmap. Yeah hi, thanks for your talk. In terms of data persistency, so databases because you show user table, a question table what options are there? Can you repeat the question I can't hear very well, sorry. So in terms of data persistency like databases what can you use? Can you use like my SQL, Postgres, DynamoDB? Yeah I mean whatever table you have available to you whatever you can connect to you I was using DynamoDB in my user table so that's really nice because it just integrates really well with the AWS just resources and whatnot. Does that answer the question or? Yes, thanks. Hey thank you for the talk and what about testing because the code you showed was really really tight coupled and oh sorry, what about testing? Yeah so in terms of testing you can go ahead and just test those general function the general handlers but in terms of actual framework if you're familiar with Flask and how it has its own testing framework Chalice doesn't really have anything specific like that but it's something we want to add in the coming days. Thank you for the talk, very nice slides thank you person for what we've seen yesterday. And my question is that you told the main difference between prior art is that you don't have a server to manage but like if you take Elastic Beanstalk for instance you also don't manage anything you just upload some artifact which speaks Whiskey and that's it like what's the difference and the serverless itself feels like a little misguiding because like you have a server on demand but you... Yeah I hear you saying so the thing with Elastic Beanstalk is that you still have the application up and running but if you're using AWS Lambda though you're only paying for the execution run time so you still may have your Elastic Beanstalk application still going and you're still paying for that resource both AWS Lambda you only have to worry about whenever it gets executed. That makes sense. Last question. Okay and another question. Okay if I get like denial of service attack and you told like the scales like they're crazy like would Amazon bill me all that DDoS? Or does it work? For the we're talking about DDoS thing. How does it work? Yeah denial of service so I get a lot of traffic the Amazon can handle it but to all my expense like how does it work? Oh yeah so what you'd have to probably set up is you can actually set up throttling through API Gateway and that'll actually handle to make sure that your Lambda function doesn't get evoked way too many times so you can avoid that. You can just kept it right? Yeah. Okay thank you. Actually I think we have time for one last question if anyone has one. Hey thank you for the talk. So I just looked it up on the internet and it seems like there are some limitations well of course it's everywhere and it seems like you can have only 1000 parallel threads like threads in process executed for one function, one Lambda function. So my question is what if you need to serve more than 1000 QPS? Can you repeat that again? I didn't catch the last part. Yeah so basically I looked at the Amazon website talking about restrictions. So there are limitations. You can run I think 1024 threads in process for one Lambda function in parallel at the same time. What if you need to serve more than 1000 QPS? I believe that's just, sorry. So I believe that's just your cap on terms of Lambda functions. In terms of having it invoke I believe that's not the limit is it? Well that's what I've seen. Maybe I may have understood it. I'm pretty sure you can only have about, you can only have 1024. I think that's what the current limit is of just simultaneous Lambda functions going. Like they're separate ones. Oh okay so it's a separate function. Chalice will have the same Lambda function for your API so you can hit that as much as you want. There won't be an issue with that. Okay it makes sense so it's not in vacations. Okay cool thanks. All right thank you everyone. All right thanks.