NestJS : des backends Node.js structurés et scalables

Un backend Node brut offre une liberté totale et presque aucune structure, ce qui explique précisément pourquoi la plupart finissent en enchevêtrement de routes, de helpers improvisés et d’imports circulaires dès qu’une équipe se forme autour. NestJS résout ce problème en imposant une architecture modulaire à injection de dépendances par-dessus TypeScript, en empruntant les patterns éprouvés d’Angular pour les appliquer au serveur. Le résultat est un framework où la forme du code est décidée avant la première fonctionnalité, si bien qu’ajouter le centième endpoint ressemble exactement à l’ajout du premier.

Les modules comme colonne vertébrale

Tout dans Nest vit à l’intérieur d’un module, une classe qui déclare ce qu’elle possède et ce qu’elle expose au reste de l’application. Cela force à tracer des frontières entre les fonctionnalités au lieu de les laisser déborder les unes sur les autres, et le graphe de dépendances entre modules devient la véritable carte de votre système :

import { Module } from '@nestjs/common';
import { UsersController } from './users.controller';
import { UsersService } from './users.service';

@Module({
  controllers: [UsersController],
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

Tout ce qui n’est pas listé dans exports reste privé au module, donc un service n’est réutilisable dans toute l’application que lorsque vous en faites le choix explicite. L’encapsulation est la valeur par défaut, pas une réflexion après coup.

L’injection de dépendances par conception

Nest embarque un conteneur IoC complet, ce qui signifie que vous n’instanciez jamais vos propres services. Vous déclarez une dépendance dans un constructeur et le framework la résout et l’injecte, câblant tout le graphe au démarrage à partir des providers que chaque module enregistre :

import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma/prisma.service';

@Injectable()
export class UsersService {
  constructor(private readonly prisma: PrismaService) {}

  findById(id: string) {
    return this.prisma.user.findUnique({ where: { id } });
  }
}

Parce que les dépendances sont injectées plutôt qu’importées directement, remplacer une implémentation réelle par un mock dans les tests tient en une ligne dans un module de test, et l’infrastructure partagée comme un client de base de données vit à un seul endroit.

Contrôleurs et décorateurs

Les contrôleurs associent les requêtes entrantes à des méthodes de traitement, et le routage s’exprime entièrement à travers des décorateurs. Le verbe HTTP, le chemin et les éléments de la requête dont vous avez besoin sont tous déclarés en ligne, ce qui garde le câblage lisible et proche de la logique qu’il pilote :

import { Controller, Get, Param } from '@nestjs/common';
import { UsersService } from './users.service';

@Controller('users')
export class UsersController {
  constructor(private readonly users: UsersService) {}

  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.users.findById(id);
  }
}

Le contrôleur reste volontairement léger. Il extrait ce dont il a besoin de la requête et délègue directement à un service, là où le vrai travail doit se trouver.

Validation avec les pipes et les DTO

Les pipes transforment et valident les données avant même qu’elles n’atteignent votre handler. Associé à une classe DTO et aux décorateurs class-validator, un seul pipe global rejette les payloads malformés en bordure, si bien que votre logique métier ne voit que des données ayant déjà respecté leur contrat :

import { IsEmail, IsString, MinLength } from 'class-validator';

export class CreateUserDto {
  @IsEmail()
  email: string;

  @IsString()
  @MinLength(8)
  password: string;
}

Enregistrer new ValidationPipe({ whitelist: true }) globalement supprime les propriétés inconnues et renvoie un 400 structuré en cas d’échec. Le DTO devient la source unique de vérité pour la forme d’une entrée, et TypeScript et la validation à l’exécution finissent enfin par s’accorder.

Les guards pour l’authentification et l’autorisation

Les guards décident si une requête a le droit d’atteindre un handler. Ils s’exécutent avant la route et ont accès au contexte d’exécution complet, ce qui en fait le foyer naturel de l’authentification, des vérifications de rôles et de toute règle d’accès devant court-circuiter la requête :

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    return Boolean(request.headers.authorization);
  }
}

Un guard peut être attaché à une seule méthode, à un contrôleur entier ou à toute l’application, vous décidez donc du rayon d’action de chaque règle sans disséminer le même if dans des dizaines de handlers.

Les interceptors pour les préoccupations transverses

Les interceptors enveloppent le handler des deux côtés de l’exécution, vous permettant d’exécuter de la logique avant le traitement de la requête et de transformer la réponse à la sortie. Le logging, le cache, le formatage de la réponse et la mesure du temps appartiennent ici plutôt que d’être dupliqués dans chaque contrôleur :

import { CallHandler, ExecutionContext, Injectable, NestInterceptor } from '@nestjs/common';
import { tap } from 'rxjs';

@Injectable()
export class LoggingInterceptor implements NestInterceptor {
  intercept(context: ExecutionContext, next: CallHandler) {
    const start = performance.now();
    return next.handle().pipe(tap(() => console.log(`${performance.now() - start}ms`)));
  }
}

Les guards, les pipes et les interceptors forment ensemble un pipeline de requête aux étapes claires, et c’est ce qui permet à un projet Nest de rester plat à mesure qu’il grandit. Le comportement transverse a une place dédiée au lieu de fuiter dans le code des fonctionnalités.

Découplé de la plateforme HTTP

Nest ne vous lie pas à un unique serveur HTTP. Il repose sur un adaptateur de plateforme, donc la même application tourne sur Express par défaut ou sur Fastify en changeant une seule ligne au démarrage, sans toucher au moindre contrôleur. La même abstraction s’étend bien au-delà du HTTP :

import { NestFactory } from '@nestjs/core';
import { FastifyAdapter } from '@nestjs/platform-fastify';
import { AppModule } from './app.module';

const app = await NestFactory.create(AppModule, new FastifyAdapter());
await app.listen(3000);

Les mêmes modules, contrôleurs et providers alimentent aussi des gateways WebSocket, des services gRPC et des microservices à base de files de messages. Vous apprenez l’architecture une fois et la réutilisez sur chaque transport dont votre système a besoin.

Conclusion

NestJS échange la liberté de la page blanche du Node brut contre quelque chose de plus précieux sur un vrai projet : une structure qui tient sous la croissance. Les modules imposent des frontières, l’injection de dépendances garde le câblage testable, et le pipeline guard-pipe-interceptor donne un foyer à chaque préoccupation transverse. C’est plus opinionné qu’un framework minimal, et c’est précisément le but. Pour des backends destinés à être maintenus par une équipe pendant des années plutôt que prototypés en un week-end, ces partis pris sont ce qui garde le code cohérent.