Debugging Full-Stack Serverless Apps
Now that we are ready to go live with our app, we need to make sure we are setup to monitor and debug errors. This is important because unlike our local environment where we can look at the console (browser or terminal), make changes and fix errors, we cannot do that when our app is live.
We need to make sure we have a couple of things setup before we can confidently ask others to use our app:
- Be alerted when a user runs into an error.
- Get all the error details, including the stack trace.
- In the case of a backend error, get the API that failed.
- Look up the logs for an API endpoint.
- Get detailed debug logs for all the AWS services.
- Catch any unexpected errors (out-of-memory, timeouts, etc.).
It’s important that we have a good view of our production environments. It allows us to keep track of what our users are experiencing.
Note that, for the frontend the setup is pretty much what you would do for any React application. But we are covering it here because we want to go over the entire debugging workflow. Right from when you are alerted that a user has gotten an error while using your app, all the way till figuring out which Lambda function caused it.
Here is what we’ll be doing in the next few chapters to help accomplish the above workflow.
On the frontend, we’ll be setting up Sentry; a service for monitoring and debugging errors. Sentry has a great free tier that we can use. We’ll be integrating it into our React app by reporting any expected errors and unexpected errors. We’ll do this by using the React Error Boundary.
On the backend, AWS has some great logging and monitoring tools thanks to CloudWatch. We’ll be using CloudWatch through the Seed console. Note that, you can use CloudWatch directly and don’t have to rely on Seed for it. We’ll also be configuring some debugging helper functions for our backend code.
Here’s what we’ll be going over in the next few chapters:
- Setting up error reporting in React
- Setting up detailed error reporting in Lambda
- The debugging workflow for the following serverless errors:
This should give you a good foundation to be able to monitor your app as it goes into production. There are plenty of other great tools out there that can improve on this setup. We want to make sure we cover the basics here. Let’s get started!
For help and discussionComments on this chapter