First: this is an awesome tutorial. Thank you so much for making it!
I’ve finished Part 2: Automation but ran into a 500 error after logging in that indicates something is wrong with the API Gateway/Lambda/DynamoDB/S3, but can’t tell which. Running npx from command line with /notes GET also gives a 500 error:
npx aws-api-gateway-cli-test \
[snipped]
--path-template='/notes' \
--method='Get'
npx: installed 103 in 6.211s
Authenticating with User Pool
Getting temporary credentials
Making API request
{ status: 500,
statusText: 'Internal Server Error',
data: { status: false } }
What is the best way to debug serverless apps like this? I’d like to add logging to help understand and debug problems. Do you have any recommended logging tool? Finally, what is the recommended development workflow? Let’s say I make some changes in the backend API, how would I test them locally without having to deploy to AWS?
What is the best way to debug serverless apps like this?
For quick issues, if you are using Seed, it should show you the CloudWatch logs. We go over this in the tutorial Redirecting…. You can also just directly use CloudWatch, we have an extra credit chapter on that - Redirecting….
Do you have any recommended logging tool?
For more in depth logging and observability, there are services like IOPipe and Dashbird.
Finally, what is the recommended development workflow?
Depending on the resources you are using, it might be very hard to have a complete local environment (even with something like serverless-offline). Instead you might need to develop locally while connecting to resources in AWS. In this case, it is better if you use a Dev or Staging environment before you push your changes to production.
Thanks Ajay for the quick reply. Yes I’m using SEED (it’s great!) and enabled logging as described in the tutorial but the log messages are not informative enough to debug the issue. I’ll look into IOPipe and serverless-offline - thanks for the pointers!
I found the problem. I changed the deployment region to us-west-2 (I’m based in Seattle) in serverless.yml but did not change the setting in dynamodb-lib.js. Classic example of why DRY principle exists.
Any thought on how to set the region in one place?
Debugging is an essential part of the development process, is it not? A walkthrough on enabling the CloudWatch logs should be an integral chapter in this course. It warrants more than just linking to it & mentioning it in passing, or making it “extra credit.” I was deeply frustrated by issues I experienced in the first part of the course–and I was roadblocked for days.
I’m thinking, right after the ‘Deploy the API’ chapter. That feels like the right place to introduce the concept of troubleshooting the API and functions.
A few additional thoughts:
My difficulties began in chapter called ‘Add a Create Note API’. I got stuck at testing the mock. There’s a point where the text says, “The response should look similar to this.” Perfect time to point out that, if you get an error instead, here’s a link to the chapter on debugging and logging. But at this point I went off track and got bogged down in googling for a solution.
And the chapter plows ahead, into the next section called ’ Refactor Our Code’. At the bottom of the page, unbeknown to me, there was a section waiting for me called ‘Common Issues.’
Here’s how I’d rather see the chapter organized: Create the API; Test the API… Here’s a resource if the test fails (EDIT: In order to setup CloudWatch on the API Gateway, don’t you have to do an sls deploy, if you haven’t already? That would be an additional consideration at that point in the course… Or hopefully we could just check logs from the Lambda service?)