Server side Node Express Debugging

Edit PagePage History

1. Debugging with console.log()

Server-side vs Browser Console Logging

When debugging Node.js and Express applications, it's crucial to understand that console.log() statements in your server code appear in a different location than those in your client-side JavaScript code:

• Server-side logs appear in the terminal/command prompt where you started your Node.js server
• Client-side logs appear in the browser's DevTools Console tab

This is a common source of confusion for beginners transitioning from front-end to full-stack development.

Where to Find Your Server Logs

When you run a Node.js application using commands like:

node
# or
node server.js
# or
npm start

Your server-side console.log() output will appear in the same terminal window. For example, when running node interactively:

Or running an app file via node server.js:

You will NOT see these logs in your browser's DevTools Console, even if they're related to web requests from that browser.

Common Debugging Scenario

Let's look at a common full-stack debugging scenario:

// server.js (Node.js/Express back-end)
app.get('/api/users', (req, res) => {
  console.log('Server: Received request for users'); // Appears in terminal
  // ... database code here ...
  res.json(users);
});

// script.js (Browser front-end)
fetch('/api/users')
  .then(response => response.json())
  .then(data => {
    console.log('Browser: Received users data', data); // Appears in browser console
  });

If you're trying to debug this application:

1. The "Server: Received request for users" message will appear in your terminal
2. The "Browser: Received users data" message will appear in your browser's console
3. If there's a problem between these two points, you'll need to check both places

Tips for Effective Server Logging

• Use descriptive prefixes like [SERVER] or [DATABASE] to quickly identify the context of logs
• Include timestamps for tracking the sequence of operations: console.log([${new Date().toISOString()}] User request received)
• Consider different log levels with console.error() for errors and console.warn() for warnings
• For production applications, consider using a robust logging library like Winston or Pino instead of console.log()

Use Cases

console.log() is the most basic and widely-used debugging tool in Node/Express applications. It allows you to quickly inspect the flow of your application and check the values of variables, request parameters, and more.

Here are some common use cases for console.log():

• Inspecting incoming data: You can log the data received in requests (such as request bodies or query parameters) to ensure that they are what you expect.
• Tracking execution flow: Add log statements at various points in your code to track where execution is going, especially if you're unsure of which part of the code is causing an issue.
• Logging error messages: You can use console.log() to log error messages when something goes wrong, which helps you understand what failed and why.

Example: Inspecting Request Data

app.post('/api/user', (req, res) => {
  console.log('Received request:', req.body);
  res.send('User data received');
});

In this example, console.log() is used to print out the body of the incoming request. This helps ensure that the correct data is being sent from the client.

Also see Debugging JavaScript with the Console Tab for more information on using console.log() for debugging.

2. Debugging with a Debugger/Breakpoint

Use Cases

Using a debugger and breakpoints allows you to pause execution at specific points in your Node/Express code, inspect variables, and step through the code line-by-line. This approach is especially useful for identifying hard-to-find bugs and understanding the flow of your application.

• Investigating issues in asynchronous code: When you're dealing with asynchronous code (like promises or async/await), the flow can sometimes be hard to follow. A debugger lets you pause and inspect the state before and after asynchronous operations.
• Debugging complex logic: For complex business logic or error-prone areas, setting breakpoints and stepping through the code can help you understand exactly what is happening at each step.

Example: Debugging Node App

When running a node app, instead of starting it with npm start, you can create a launch.json file, and subsequently, running it with the run & debug button in VSCode will start a debug session, allowing breakpoints to be set and the execution to be paused at those breakpoints. Step-by-step instructions:

1. Create a launch.json file in the .vscode directory of your project. Save the default configuration.
2. Run the app with the run & debug button in VSCode.

1. Set breakpoints in your code.
2. Run the app again and it will pause at the breakpoints.

Also see Debugging JavaScript with Breakpoints for more information on using breakpoints and the debugger.

3. Debugging API Requests & Responses

Using Insomnia for Debugging API Requests & Responses

When developing server-side applications, it's essential to test and debug API requests and responses to ensure that the server is receiving and responding to requests correctly. Tools like Postman and Insomnia are great for simulating and testing API calls.

Example: Inspecting an API Response in Insomnia

1. Open Insomnia and create a new Request.
2. Select the request method (e.g., GET, POST).
3. Enter the URL of your API endpoint (e.g., http://localhost:3000/api/user).
4. Click Send to send the request.
5. Inspect the response body, headers, and status code to ensure that everything is working as expected.

You can use console.log on the server to log the request data and response as follows:

app.post('/api/user', (req, res) => {
  console.log('Request Body:', req.body);
  res.status(200).json({ message: 'User data received' });
});

Now, when you send the POST request from Insomnia, you'll see the request body logged on the server console.

For more detailed guidance, visit the Insomnia Documentation.

4. Debugging Database Queries

Logging Prisma Queries and Errors

When using Prisma in a Node/Express app, it's helpful to log queries and errors to troubleshoot database interactions. Prisma provides a built-in logging feature that can help track queries, warnings, and errors.

Example: Logging Prisma Queries

You can enable Prisma logging for queries by configuring it in the Prisma client setup:

const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient({
  log: ['query', 'info', 'warn', 'error'],
});

prisma.user.findMany().then(users => {
  console.log(users);
});

This logs all queries, including their parameters and results. You can view the queries in the console to ensure they are being executed as expected.

Debugging Database Connections in Prisma

If you're experiencing issues with database connections, Prisma provides logs that can help you identify connection failures. Prisma uses the underlying database client to make connections, so you can log database connection information to see if there are issues.

Example: Debugging Connection Issues

const prisma = new PrismaClient({
  log: ['query', 'info', 'warn', 'error'],
});

prisma.$connect().catch(error => {
  console.error('Database connection error:', error);
});

This will log the connection attempt, and if there's an error connecting to the database, it will be displayed in the console.

Debugging Connection Issues in Prisma

Common connection issues include incorrect credentials, database unreachable errors, and misconfigured environment variables. To troubleshoot:

1. Check the database URL in your .env file to make sure the connection string is correct.
2. Ensure your database is running: Verify that your database service (e.g., PostgreSQL, MySQL) is running and accessible.
3. Check Prisma schema: Ensure your Prisma schema is up to date and matches the database structure.

Example: Checking the Database URL

DATABASE_URL="postgresql://user:password@localhost:5432/mydb?schema=public"

Make sure the connection string is correct for your environment. If the database is remote, ensure that the IP/hostname and credentials are correct.

Using Prisma Studio for Interactive Debugging

Prisma Studio is a visual interface for interacting with your Prisma database. It allows you to view and manipulate records directly from your database, which can be extremely useful for debugging.

Example: Using Prisma Studio

1. To launch Prisma Studio, run the following command in your project:

npx prisma studio

1. This opens a web interface where you can view and edit data in your database.
2. You can use Prisma Studio to verify if records exist, check relationships, and validate if the data in your database matches what your API expects.

Prisma Studio provides an intuitive UI to perform CRUD operations, inspect records, and troubleshoot issues related to data in the database.

For more details, refer to the official Prisma Studio Documentation.

More Resources

• 🎥 Video: How to debug Node.js in Visual Studio Code (10 min)
• 🎥 Video: Insomnia Tutorial (5 min)
• 🎥 Video: Prisma in 100 Seconds (2.5 min)
• Node.js Debugging Documentation
• Prisma Documentation
• Prisma Logging Configuration
• Insomnia Documentation

By utilizing console.log(), breakpoints, API testing tools like Insomnia, and Prisma's built-in debugging features, you can effectively debug server-side Node/Express applications and handle common issues related to database connections and queries.