Why providers encapsulate business logic in NestJS - Performance Evidence

Performance: Why providers encapsulate business logic

MEDIUM IMPACT

This affects the rendering speed and responsiveness by organizing code to minimize unnecessary computations and side effects during request handling.

Organizing business logic in a NestJS application

NestJS

import { Injectable, Controller, Get } from '@nestjs/common';

@Injectable()
export class UserService {
  getActiveUsers() {
    const users = this.fetchUsersFromDb();
    return users.filter(u => u.isActive);
  }

  private fetchUsersFromDb() {
    return [{ id: 1, isActive: true }, { id: 2, isActive: false }];
  }
}

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Get()
  getUsers() {
    return this.userService.getActiveUsers();
  }
}

Separating business logic into a provider (UserService) allows reuse, easier testing, and avoids redundant logic in controllers, improving response time and maintainability.

📈 Performance GainReduces redundant logic execution and improves code reuse, lowering CPU load and improving input responsiveness.

Organizing business logic in a NestJS application

NestJS

import { Controller, Get } from '@nestjs/common';

@Controller('users')
export class UserController {
  @Get()
  getUsers() {
    // Business logic directly in controller
    const users = fetchUsersFromDb();
    const filtered = users.filter(u => u.isActive);
    return filtered;
  }
}

function fetchUsersFromDb() {
  // Simulate DB fetch
  return [{ id: 1, isActive: true }, { id: 2, isActive: false }];
}

Placing business logic directly in controllers causes tight coupling and repeated logic execution on each request, increasing processing time and reducing maintainability.

📉 Performance CostTriggers repeated computations on every request, increasing CPU usage and response time.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Business logic in controller	N/A	N/A	N/A	[X] Bad
Business logic in provider	N/A	N/A	N/A	[OK] Good

Rendering Pipeline

Encapsulating business logic in providers separates concerns, so controllers handle routing and providers handle data processing. This reduces unnecessary computations during request handling, improving responsiveness.

→JavaScript Execution

→Event Handling

⚠️ BottleneckExcessive logic in controllers causing repeated computations

Core Web Vital Affected

INP

This affects the rendering speed and responsiveness by organizing code to minimize unnecessary computations and side effects during request handling.

Optimization Tips

1Keep business logic in providers, not controllers, to avoid repeated computations.

2Use providers to organize code for reuse and easier testing.

3Reducing logic in controllers improves input responsiveness and lowers CPU load.

Performance Quiz - 3 Questions

Why does placing business logic directly in controllers reduce performance?

A It reduces the number of HTTP requests

B It improves caching automatically

C It causes repeated logic execution on every request increasing CPU load

D It decreases bundle size

DevTools: Performance

How to check: Record a performance profile while making requests to the API endpoints. Look for long scripting times or repeated function calls in the call tree.

What to look for: High CPU usage or repeated execution of business logic functions in controllers indicates poor separation.