DEV Community: Benjamin Raffetseder

How To Keep Track Of Responses In NestJS

Benjamin Raffetseder — Sun, 25 Aug 2024 16:16:25 +0000

In backend development, effective logging is essential for maintaining a healthy and efficient system. It provides insights into the behavior of your application, aiding in debugging, troubleshooting, and performance optimization. NestJS offers a way to implement custom middleware, including logging mechanisms.

Introducing the Response Middleware

In this blog post, we will explore how to create a response logging middleware in NestJS. This middleware will log the incoming request, the response status, and the response time. By implementing this middleware, you can keep track of the requests and responses in your application, which is essential for monitoring and debugging.

Here's an example of a response logging middleware in NestJS:

import { Injectable, Logger, NestMiddleware } from '@nestjs/common'
import type { NextFunction, Request, Response } from 'express'

@Injectable()
export class ResponseMiddleware implements NestMiddleware {
  logger = new Logger('Response')

  constructor() {}

  /**
   * This middleware logs the request and response status code in the console.
   * The format of the log is:
   * <METHOD> <URL> <STATUS CODE> <RESPONSE TIME IN MS>
   *
   * @param {Request} req - The incoming request
   * @param {Response} res - The outgoing response
   * @param {NextFunction} next - The next middleware in the stack
   */
  use(req: Request, res: Response, next: NextFunction) {
    const { method, originalUrl } = req
    const requestStartTime = new Date().getTime()

    /**
     * This event is emitted when the response is finished.
     * We log the request and response information in this listener.
     */
    res.on('finish', () => {
      const { statusCode } = res

      const responseTime = new Date().getTime()
      const duration = responseTime - requestStartTime
      const message = `${method} ${originalUrl} ${statusCode} ${duration}ms`

      /**
       * Log the request and response information in the console.
       */
      this.logger.log(message)
    })

    /**
     * Call the next middleware in the stack.
     */
    next()
  }
}

How It Works

The ResponseMiddleware class implements the NestMiddleware interface, which requires the implementation of a use method. This method is called for each incoming request, and it takes three parameters: req (the incoming request), res (the outgoing response), and next (the next middleware in the stack).

In the use method, we extract the HTTP method and the URL from the incoming request. We also record the start time of the request using new Date().getTime(). We then attach an event listener to the finish event of the response object. This event is emitted when the response is finished and ready to be sent back to the client.

When the finish event is triggered, we calculate the response time by subtracting the start time from the current time. We then construct a log message containing the HTTP method, URL, status code, and response time. Finally, we log this message using the Logger class provided by NestJS.

Key Features

Enhanced Monitoring: By logging detailed information about each request and response, you can monitor your application's performance and identify slow endpoints.
Simplified Debugging: The logs provide valuable insights into the behavior of your application, making it easier to debug issues and understand the flow of requests.
Performance Optimization: By analyzing the response times, you can identify bottlenecks and optimize the performance of your application.

Registering the Middleware

To use this middleware in your NestJS application, you need to register it in the appropriate module. Here's how you can register the ResponseMiddleware:

import { MiddlewareConsumer, Module, NestModule } from '@nestjs/common'
import { ResponseMiddleware } from './response.middleware'

@Module({})
export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(ResponseMiddleware).forRoutes('*') // Apply the middleware to all routes
  }
}

Conclusion

In conclusion, implementing a response logging middleware in NestJS is a simple yet powerful way to enhance the monitoring and debugging capabilities of your backend.

You could extend this middleware to log additional information such as request headers, response headers, and request body or even integrate it with 3rd-party logging services.

Simplifying Async Error Handling in TypeScript

Benjamin Raffetseder — Fri, 23 Aug 2024 10:30:06 +0000

If you've worked with asynchronous code in TypeScript for any length of time, you'll know that error handling can get messy fast. Between nested try-catch blocks and repetitive error-handling logic, it doesn't take long before your codebase starts feeling cluttered. That's why I've found myself leaning toward a more elegant solution — the tryCatch helper function. This little utility is inspired by Go's error-handling approach and wraps your async functions in a way that simplifies error management, making your code more readable and maintainable.

The Code

Let's jump right into the tryCatch function:

export const tryCatch = async <T>(fn: () => Promise<T>, logError = false): Promise<[T | undefined, Error | undefined]> => {
  try {
    const data = await fn();
    return [data, undefined];
  } catch (error: unknown) {
    const err = error instanceof Error ? error : new Error(String(error));

    if (logError) {
      console.error(err);
    }

    return [undefined, err];
  }
}

Why I Use This Approach

As someone who's spent a lot of time dealing with asynchronous code, I've come to really appreciate the benefits tryCatch brings to the table:

Cleaner Code: One of the biggest advantages is that tryCatch helps reduce the number of try-catch blocks scattered throughout your code. This may seem like a small thing, but when you're managing multiple async operations, it makes a big difference in keeping your code readable and manageable. Instead of having multiple try-catch blocks everywhere, you deal with both success and error cases in a predictable, clean way. And as a bonus, this approach makes it easier for others to read your code and understand what's going on.
Consistent Error Handling: One thing that I've learned over the years is that consistent error handling is key to a maintainable codebase. With tryCatch, you establish a clear and uniform pattern for handling errors across your code. This not only reduces mental overhead but also makes your codebase easier to maintain as it scales.
Optional Logging: Sometimes you want to log errors right away, sometimes you don't. The optional logError flag gives you the flexibility to toggle error logging on or off, depending on what makes sense for the situation. This keeps your code free from repetitive console logs calls and allows for centralized logging behavior.
Type Safety: Since we're working with TypeScript, type safety is always on my mind. tryCatch ensures that if an error occurs, the result will be undefined, and vice versa. This reduces the chances of those frustrating runtime bugs that crop up because of type mismatches. Plus, it's a nice reassurance when you're juggling complex data flows.

Example Usage:

   const [data, error] = await tryCatch(async () => {
     // Your async logic here
   }, true);
   if (error) {
     // Handle the error
   } 
   if (!data) {
    // Handle the absence of data
   }
   // Continue with the data

Why It's Better Than Traditional `try-catch`

I've seen plenty of projects where traditional try-catch blocks work well—at first. But as the project grows and async operations multiply, they start to become a headache. Here's how tryCatch can make things easier:

No Deep Nesting: Once you start nesting multiple try-catch blocks, it's easy to lose track of what's happening where. tryCatch helps keep your code flatter, which makes the logic easier to follow.
Single Responsibility: This function allows you to encapsulate error handling in a single place. I like to think of it as aligning with the single responsibility principle — your async functions focus on what they're supposed to do, while tryCatch handles the errors. This separation makes the code easier to read and maintain.
Focus on the Happy Path: One of my favorite things about using tryCatch is how it allows me to focus on the happy path in my code. Instead of constantly breaking the flow to deal with errors, I can keep my main logic straightforward and handle the errors separately. This small shift can make a big difference when you're trying to keep the overall intent of your code clear.

Final Thoughts

As someone who's been building with TypeScript for a while now, I've found tryCatch to be a real asset in managing asynchronous error handling. It's one of those small changes that have a surprisingly big impact, especially when you're working in a large or growing codebase. By reducing noise and ensuring consistent error handling, tryCatch helps me write cleaner, more maintainable code.

If you haven't tried it yet, give it a go — it might just make your life a little easier too.

I just launched my first real side project!

Benjamin Raffetseder — Thu, 19 Sep 2019 15:27:45 +0000

First of all, hi dev.to community!

This is my first post, I've been here a little longer but actually just spent the most of the time lurking.

As I mentioned above I just "finished" my side project called "deliciously.cooking". It's a mix between a traditional recipe site and Tinder.

I know that sometimes finding something that you actually want to cook can be a big struggle if you get a big overview of all recipes. That's why designed & developed this site. You just a random selection of cards and if you see what you like you can get further information about it.

What's under the hood?

The site runs on Drupal and Vue. The explore page gets the recipes via an API using Vue to fetch and display them.

Users are able to register and upload own recipes over a simple form. They're also able to save other recipes to their account.

Is this project done?

No, it's far away from being finished, at least in my opinion! I still have a lot of ideas which I want to add. (Also some bugs to fix)

I also need to promote and get users to the platform. Maybe you have interest in it and have a look?

deliciously.cooking