Functional middleware in NestJS - Performance & Optimization

Performance: Functional middleware

MEDIUM IMPACT

Functional middleware affects request processing speed and server response time by controlling how requests flow through the middleware stack.

Handling HTTP requests with middleware in NestJS

NestJS

export function fastMiddleware(req, res, next) {
  // Non-blocking async operation example
  setImmediate(next);
}

Uses non-blocking async call to avoid event loop blocking, allowing other requests to be processed concurrently.

📈 Performance GainNo event loop blocking, reduces INP and improves server responsiveness

Handling HTTP requests with middleware in NestJS

NestJS

export function slowMiddleware(req, res, next) {
  // Simulate heavy synchronous task
  const start = Date.now();
  while (Date.now() - start < 100) {}
  next();
}

This middleware blocks the event loop with a synchronous delay, causing slow request processing and poor responsiveness.

📉 Performance CostBlocks event loop for 100ms per request, increasing INP and delaying response

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Blocking synchronous middleware	N/A (server-side)	N/A	N/A	[X] Bad
Non-blocking async middleware	N/A (server-side)	N/A	N/A	[OK] Good

Rendering Pipeline

Functional middleware runs on the server before the response is sent. It affects the server's ability to quickly process and forward requests, impacting how fast the client receives content.

→Request Handling

→Middleware Execution

→Response Sending

⚠️ BottleneckBlocking synchronous code inside middleware delays the entire request pipeline.

Core Web Vital Affected

INP

Functional middleware affects request processing speed and server response time by controlling how requests flow through the middleware stack.

Optimization Tips

1Avoid synchronous blocking code in middleware to keep the event loop free.

2Use asynchronous APIs and minimal logic inside middleware for faster request handling.

3Profile middleware execution time to identify and fix slow operations.

Performance Quiz - 3 Questions

What is the main performance risk of using synchronous code inside functional middleware in NestJS?

A It blocks the event loop, delaying all incoming requests.

B It increases the size of the client bundle.

C It causes layout shifts in the browser.

D It reduces CSS selector specificity.

DevTools: Network panel in browser DevTools and server profiling tools

How to check: Use the Network panel to measure server response times and use Node.js profiling or logging to check middleware execution duration.

What to look for: Look for long server response times or middleware functions that block the event loop causing delayed responses.

Practice

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

easy

A. To run code before the route handler to modify requests or add features

B. To define database models for the application

C. To create UI components for the frontend

D. To compile TypeScript code into JavaScript

Solution

1. Step 1: Understand middleware role

   Middleware runs before route handlers to process requests or add features like logging or authentication.

2. Step 2: Identify correct purpose

   Options A, B, and D relate to other parts of development, not middleware.

3. Final Answer:

   To run code before the route handler to modify requests or add features -> Option A

4. Quick Check:

   Middleware runs before routes = C [OK]

Hint: Middleware runs before routes to add features [OK]

Common Mistakes:

• Confusing middleware with database models
• Thinking middleware creates UI components
• Believing middleware compiles code

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

easy

A. function logger(req, res) { console.log(req.url); }

B. class Logger { log(req, res) { console.log(req.url); } }

C. const logger = () => { console.log('log'); }

D. function logger(req, res, next) { console.log(req.url); next(); }

Solution

1. Step 1: Check middleware signature

   Functional middleware must accept (req, res, next) and call next() to continue.

2. Step 2: Validate options

   function logger(req, res, next) { console.log(req.url); next(); } matches this pattern. class Logger { log(req, res) { console.log(req.url); } } is a class, not functional middleware. const logger = () => { console.log('log'); } lacks parameters and next call. function logger(req, res) { console.log(req.url); } misses next parameter and call.

3. Final Answer:

   function logger(req, res, next) { console.log(req.url); next(); } -> Option D

4. Quick Check:

   Middleware needs (req, res, next) and calls next() [OK]

Hint: Middleware needs (req, res, next) and calls next() [OK]

Common Mistakes:

• Omitting the next parameter
• Not calling next() inside middleware
• Using class instead of function for functional middleware

3. Given this middleware code, what will be logged when a request to '/home' is made?

function logger(req, res, next) {
  console.log('Request URL:', req.url);
  next();
}

medium

A. Request URL: undefined

B. Request URL: /home

C. No output because next() stops logging

D. Error: req.url is not defined

Solution

1. Step 1: Understand req.url property

   In middleware, req.url contains the path of the incoming request, here '/home'.

2. Step 2: Analyze console.log output

   The middleware logs 'Request URL:' followed by req.url, so it prints 'Request URL: /home'.

3. Final Answer:

   Request URL: /home -> Option B

4. Quick Check:

   req.url logs request path = A [OK]

Hint: req.url holds the request path string [OK]

Common Mistakes:

• Assuming next() stops console.log
• Thinking req.url is undefined
• Confusing middleware with route handler output

4. Identify the error in this functional middleware code:

function auth(req, res, next) {
  if (!req.headers.authorization) {
    res.status(401).send('Unauthorized');
  }
  next();
}

medium

A. res.status should be res.sendStatus

B. Missing req parameter in function signature

C. next() is called even after sending response, causing errors

D. Authorization header check is incorrect

Solution

1. Step 1: Analyze flow after sending response

   If authorization header is missing, response is sent with 401, but next() is still called, which can cause errors by continuing the request cycle.

2. Step 2: Identify correct fix

   To fix, add return before res.status(401).send(...) to stop execution or call next() only if authorized.

3. Final Answer:

   next() is called even after sending response, causing errors -> Option C

4. Quick Check:

   Call next() only if no response sent [OK]

Hint: Don't call next() after sending response [OK]

Common Mistakes:

• Calling next() after res.send causes errors
• Forgetting to stop middleware after response
• Misusing res.status vs res.sendStatus

5. You want to create a functional middleware that adds a custom header 'X-App-Version' with value '1.0' to every response. Which code correctly implements this?

hard

A. function addVersion(req, res, next) { res.setHeader('X-App-Version', '1.0'); next(); }

B. function addVersion(req, res) { res.setHeader('X-App-Version', '1.0'); }

C. function addVersion(req, res, next) { next(); res.setHeader('X-App-Version', '1.0'); }

D. function addVersion(req, res, next) { req.setHeader('X-App-Version', '1.0'); next(); }

Solution

1. Step 1: Confirm middleware signature and header setting

   Middleware must accept (req, res, next) and call next() after setting headers. res.setHeader is correct method.

2. Step 2: Evaluate options

   function addVersion(req, res, next) { res.setHeader('X-App-Version', '1.0'); next(); } sets header then calls next() correctly. function addVersion(req, res) { res.setHeader('X-App-Version', '1.0'); } misses next parameter and call. function addVersion(req, res, next) { next(); res.setHeader('X-App-Version', '1.0'); } calls next() before setting header, so header may not be sent. function addVersion(req, res, next) { req.setHeader('X-App-Version', '1.0'); next(); } uses req.setHeader which is incorrect because req cannot set response headers.

3. Final Answer:

   function addVersion(req, res, next) { res.setHeader('X-App-Version', '1.0'); next(); } -> Option A

4. Quick Check:

   Set header before next() with correct method [OK]

Hint: Set header before next() using res.setHeader [OK]

Common Mistakes:

• Calling next() before setting headers
• Omitting next parameter or call
• Confusing req and res when setting headers