Run lambda functions built with CDK locally using AWS SAM
Building and debugging lambda functions can be tricky.
Once a function becomes non-trivial, the cycle of:
- build
- deploy to AWS
- test
- fix
- repeat
wastes a lot of time. Luckily, there's an alternative.
In this quick lesson we're going to learn how to use AWS Serverless Application Model (SAM) command line interface in order to execute a lambda function built with CDK locally.
This lesson is a bit optional because it touches a topic that is not going to be relevant for the rest of this course (although running lambda functions locally is really useful).
If you'd like to learn more about AWS SAM, there's a whole collection about it: Build serverless applications with AWS Serverless Application Model (AWS SAM)
Instructor: [0:00] Right now our Lambda function is fairly small. It's basically only returning this object with a status code of 200 and also a body.
[0:06] If you want to expand this function, it will be useful to be able to call this function locally. We don't have to redeploy this function to AWS every single time we want to make a new change.
[0:15] This is possible with CDK but in order to make it work, we have to also have serverless application model installed.
[0:20] To check if you already have serverless application model installed, run SAM --help in your terminal. As you can see over here, I do have the AWS serverless application model installed.
[0:30] If you don't, there's a link to the description of this video on how to install it. There's also a whole collection of videos about serverless application model. If you don't have it installed, it's also fine. The rest of this course is not going to use the AWS serverless application model.
[0:42] In order to run the Lambda function locally, first, we have to generate a CloudFormation template. To do that, run CDK synth --no-staging and we're going to pipe it to template.yaml file. We can see that file over here.
[0:55] We can also compare how much code we don't have to maintain because all of this is the CloudFormation template that is actually being used in order to deploy our infrastructure. The only code that we have to maintain is this part.
[1:05] In any case, here we can see the logical id of our Lambda function. That is exactly what we need in order to be able to code this function locally.
[1:12] Let me go ahead and copy that. Next in our terminal, we're going to call sam local invoke, and paste in the logical id of this function. Before we are able to do that, we need to have Docker installed.
[1:23] I'm going to start Docker and try again. If you don't have Docker on the machine, this is fine. Like I said, this lesson is a bit optional.
[1:28] Now that Docker is up and running, let me go ahead and call this function again. This is going to invoke our hello.handler Lambda function. We can see the response that we defined in our Lambda function over here also pop up in the response.
[1:41] We do have the status code of 200. Also we have the body of "Hello, Egghead friends. You've hit undefined."
[1:46] The reason why we are seeing undefined is that we are not passing any event to this function. Luckily, with serverless application model, we can also pass in custom events to our Lambda function to be able to test them locally a bit better.
[1:58] In the source code for this lesson, there is a folder sample events which contains a hello.json file, which contains a simple event. It is an object with a path set to hello/egghead and also a body of hello.
[2:09] Let me go ahead, clear the terminal. We are going to call this function passing in this event. I'm going to do --event = sampleEvents/hello.json.
[2:21] We can see that because we have defined the path in our sample event, the body of this Lambda function response is going to contain this event path and is actually being logged out over here. Right now, the body of our local Lambda function response contains a string of hello "Egghead friends, you've hit hello/egghead."