Creating middleware in NestJS - Performance Optimization Steps

Performance: Creating middleware

MEDIUM IMPACT

Middleware affects request processing speed and can impact server response time and client perceived latency.

Adding logging to requests

NestJS

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

@Injectable()
export class LoggingMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    setImmediate(() => {
      console.log(`Request to ${req.url}`);
    });
    next();
  }
}

Defers logging asynchronously, allowing the request to continue without blocking the event loop.

📈 Performance GainNon-blocking middleware reduces INP and improves server responsiveness.

Adding logging to requests

NestJS

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

@Injectable()
export class LoggingMiddleware implements NestMiddleware {
  use(req: Request, res: Response, next: NextFunction) {
    // Synchronous heavy computation
    for (let i = 0; i < 1e7; i++) {}
    console.log(`Request to ${req.url}`);
    next();
  }
}

Heavy synchronous work blocks the event loop, delaying all requests and responses.

📉 Performance CostBlocks event loop for 50-100ms per request, increasing INP and overall latency.

Performance Comparison

Pattern	Event Loop Blocking	Request Latency	Concurrency Impact	Verdict
Synchronous heavy work in middleware	High (blocks event loop)	High latency per request	Low concurrency	[X] Bad
Asynchronous non-blocking middleware	None (event loop free)	Low latency	High concurrency	[OK] Good

Rendering Pipeline

Middleware runs during the server request processing pipeline before the final response is sent. It affects how fast the server can respond and how quickly the client receives data.

→Request Handling

→Event Loop

→Response Generation

⚠️ BottleneckBlocking synchronous code in middleware stalls the event loop, delaying all requests.

Core Web Vital Affected

INP

Middleware affects request processing speed and can impact server response time and client perceived latency.

Optimization Tips

1Avoid synchronous heavy work in middleware to prevent blocking the event loop.

2Use asynchronous operations in middleware to keep the server responsive.

3Keep middleware logic minimal and non-blocking to improve request handling speed.

Performance Quiz - 3 Questions

What is the main performance risk of synchronous heavy computation inside NestJS middleware?

A It increases CSS paint time in the browser.

B It blocks the event loop, delaying all requests.

C It causes layout shifts on the client side.

D It reduces the bundle size.

DevTools: Performance

How to check: Record a server profile or use Node.js profiling tools to check event loop delays during request handling.

What to look for: Look for long blocking tasks or event loop stalls indicating synchronous blocking in middleware.

Practice

1. What is the main purpose of middleware in a NestJS application?

easy

A. To handle server errors automatically

B. To define database models

C. To run code before the request reaches the route handler

D. To create UI components

Solution

1. Step 1: Understand middleware role

   Middleware is code that runs before the main route handler processes a request.

2. Step 2: Compare options

   Only To run code before the request reaches the route handler describes this behavior correctly; others describe unrelated tasks.

3. Final Answer:

   To run code before the request reaches the route handler -> Option C

4. Quick Check:

   Middleware runs before routes [OK]

Hint: Middleware always runs before route handlers [OK]

Common Mistakes:

• Confusing middleware with controllers
• Thinking middleware handles UI rendering
• Assuming middleware manages database models

2. Which of the following is the correct way to define a middleware class in NestJS?

easy

A. const MyMiddleware = (req, res, next) => { next(); }

B. class MyMiddleware { handle(req, res, next) { next(); } }

C. function MyMiddleware(req, res, next) { next(); }

D. class MyMiddleware { use(req, res, next) { next(); } }

Solution

1. Step 1: Recall NestJS middleware pattern

   Middleware must be a class with a method named use that takes req, res, next.

2. Step 2: Check options

   Only class MyMiddleware { use(req, res, next) { next(); } } defines a class with a use method correctly. class MyMiddleware { handle(req, res, next) { next(); } } uses handle, which is invalid. Options C and D define functions, not classes.

3. Final Answer:

   class MyMiddleware { use(req, res, next) { next(); } } -> Option D

4. Quick Check:

   Middleware class must have use() method [OK]

Hint: Middleware class must have a use() method [OK]

Common Mistakes:

• Using method name other than use
• Defining middleware as a function instead of class
• Forgetting to call next() inside use

3. Given this middleware class, what will be logged when a request to '/some-path' hits the route?

class LoggerMiddleware {
  use(req, res, next) {
    console.log('Request URL:', req.url);
    next();
  }
}

medium

A. Request URL: /some-path

B. Request URL: undefined

C. No output because next() is missing

D. Error: use method not found

Solution

1. Step 1: Analyze middleware behavior

   The middleware logs the request URL from req.url and then calls next() to continue.

2. Step 2: Predict output

   When a request to '/some-path' arrives, it logs 'Request URL: /some-path'. No errors occur because use is defined and next() is called.

3. Final Answer:

   Request URL: /some-path -> Option A

4. Quick Check:

   Middleware logs req.url correctly [OK]

Hint: Middleware logs req.url before calling next() [OK]

Common Mistakes:

• Forgetting to call next() causing no further processing
• Assuming req.url is undefined
• Confusing method name use with handle

4. What is wrong with this middleware code?

class LoggerMiddleware {
  use(req, res, next) {
    console.log('Request received');
  }
}

export class AppModule implements NestModule {
  configure(consumer: MiddlewareConsumer) {
    consumer.apply(LoggerMiddleware).forRoutes('users');
  }
}

medium

A. Missing call to next() inside LoggerMiddleware

B. MiddlewareConsumer must be imported from '@nestjs/common' not '@nestjs/core'

C. The configure method should return a value

D. No semicolon after forRoutes call

Solution

1. Step 1: Check middleware code

   The registration uses MiddlewareConsumer correctly, but examine the LoggerMiddleware class.

2. Step 2: Identify the error

   The use method does not call next(), causing the request to hang without reaching the route handler.

3. Final Answer:

   Missing call to next() inside LoggerMiddleware -> Option A

4. Quick Check:

   Middleware must call next() to continue [OK]

Hint: Always call next() inside middleware use() method [OK]

Common Mistakes:

• Forgetting next() call causing request hang
• Thinking configure must return a value
• Confusing import sources for MiddlewareConsumer

5. You want to apply a middleware only to POST requests on the '/login' route. How can you achieve this in NestJS?

hard

A. Use consumer.apply(MyMiddleware).forRoutes('/login') and check method inside middleware

B. Use consumer.apply(MyMiddleware).forRoutes({ path: '/login', method: RequestMethod.POST })

C. Apply middleware globally and filter POST requests inside middleware

D. NestJS does not support method-specific middleware

Solution

1. Step 1: Understand method-specific middleware application

   In NestJS, you can specify route and HTTP method using an object with path and method in forRoutes.

2. Step 2: Evaluate options

   Use consumer.apply(MyMiddleware).forRoutes({ path: '/login', method: RequestMethod.POST }) correctly uses { path: '/login', method: RequestMethod.POST }. Use consumer.apply(MyMiddleware).forRoutes('/login') and check method inside middleware applies middleware to all methods on '/login', requiring manual filtering. Apply middleware globally and filter POST requests inside middleware applies globally, which is less efficient. NestJS does not support method-specific middleware is false.

3. Final Answer:

   Use consumer.apply(MyMiddleware).forRoutes({ path: '/login', method: RequestMethod.POST }) -> Option B

4. Quick Check:

   Use forRoutes with path and method object [OK]

Hint: Use forRoutes with path and method object for specific HTTP verbs [OK]

Common Mistakes:

• Applying middleware to all methods unintentionally
• Not importing RequestMethod enum
• Assuming method-specific middleware is unsupported