How To Quickly Debug AWS Lambda - VS Code & Serverless Framework

❗️Today I share two tips to quickly debug Lambda functions using Serverless Framework and VS code.
1. VSCode debugger
2. Mock your Lambda event
🧠 Whatever you do, absolutely do not push to the cloud every time you want to test a change!
---
WHO AM I: I'm Dylan, a Cloud Engineer living in Bend, Oregon. I use my background in tech to make videos about technology that enables and grows businesses.
---
🌍 My website / blog -
dylanalbertazz...

[@jonlinnell4388]

Nice video. I generally prefer to pass a mock event into the function to simulate an invocation, rather than hardcoding a local `body` object.

[@dylanalbertazzi]

Absolutely, this was a quick and dirty example. Lately I've been printing the request body in the function then getting the output in cloudformation to use as the mock event.

[@SagarBhamidipati]

Can we also debug by connecting to DynamoDB? If you have instructions, please prepare a video on how to debug connecting local to DynamoDB.

[@gabrielrodriguesricardo]

amazing video! Excellent best practices

[@rw-dc]

This is awesome. Is there a way to activate the breakpoints from a serverless offline function as well?

[@ToreyLittlefield]

Great stuff thank you

[@dylanalbertazzi]

Glad it was helpful!

That's a great tutorial, but how would you debug a function locally that has cloud context? For example, a Lambda function that can only be accessed by logged-in users, needs to write to DynamoDB and needs to access SSM secrets?

[@dylanalbertazzi]

You can do the type of stuff your talking about with Serverless framework and the aws-sdk. SSM parameters can be accessed directly from serverless framework or with the aws-sdk. Dynamo is accessed through the sdk and as long as you set the correct IAM roles, it will work. Depending on your Auth, there are ways to get around. If your locking functions down at the API gateway level there shouldn't be a problem invoking the function directly.

[@JaimeCaicedo]

You can use serverless-offline plugin for lambda and apigateway. You can also use dynamadb-offline plugin or local stack for a full cloud locally

@@JaimeCaicedo I'm going to try those out, thanks for the tips!

[@Rock-ks1gd]

how to send file in api?

[@rogerolivedelgado7182]

Nice video! I'm trying to debug lambda locally but execution takes around 25 seconds. Lambda just retreives data from Timestream Database. I'm trying to use any option that could avoid rebuilding each time docker containers, do you have any idea or do you have found a similar problem when interacting with resources deployed on the cloud such as databases?

[@dylanalbertazzi]

How are you running the function? It shouldn't matter if your talking to a database or not.

[@RougeCognito]

Remind me again why we should add a huge overhead to development by using FaaS instead of just using Docker/Fargate? Lambdas are very powerful but they are a terrible replacement for a full backend micro-service.

[@dylanalbertazzi]

Lambda is an piece important piece of a common AWS micro service. Commonly it's paired with API Gateway, dynamo db, s3, etc. If your organization already has tooling built around containers Docker/Fargate can be the most cost effective option. I see containers as a good option if you have long running workloads (max is 15 min on lambda). Other than that lambda is incredibly cheap, less overhead than docker (no need to manage images), and generally integrates better into the rest of the AWS services. If you're interested on microservice best practices you'll like this article: docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html

[@abhinasutra143]

will it work if docker not installed?

[@dylanalbertazzi]

I've never tried. Is there any reason you don't want to install docker?

[@praveenksharma777]

I believe one needs Docker when you are using SAM or something. Here you are calling the function directly. So no need for Docker.

[@deemon710]

Did he leave the mock data in there? So now 1 loaf of bread is gonna be 1 16 kcal carrot? lol

[@gracewood6768]

i was doing this but im having problem on the ERR! that says package.json can't be found. THe compiler finds teh package.json on ${workspaceFolder}/package.json but it should be ${workspaceFolder}/lambdaNameFolder/package.json How can the compiler see it on another folder? Please help me! Thank you

[@dylanalbertazzi]

Hi Grace, The best option depends on your use case but you have two options. 1. move the package.json into the workspace folder 2. run npm init in the lambdaNameFolder. This will make everything in the lambdaNameFolder a separate service.