backend
Pourquoi NestJS pour un back-end devenu gros
Pourquoi NestJS pour un back-end devenu gros
C'est un framework Node à opinions — modules, injection de dépendances, décorateurs, style Angular, posé sur Express par défaut. Toute l'API de ma plateforme tourne dessus.
Express nu donne une liberté totale et zéro structure. C'est correct pour une petite API et pénible au-delà d'une vingtaine de domaines métier, chacun ayant besoin de ses propres services, DTO et guards. NestJS impose une forme cohérente à chaque module — *.module.ts, *.controller.ts, *.service.ts — et cette cohérence est ce qui garde une grosse base de code navigable quand il n'y a qu'une personne qui tient toute la carte.
Les modules sont l'unité d'organisation. Chaque domaine — applications/, payments/, messaging/ — importe seulement ce dont il a besoin de core/ et exporte seulement ce que les autres modules devraient utiliser. C'est ce qui empêche un domaine de fouiller dans les entrailles d'un autre.
L'injection de dépendances — les services sont des providers, injectés par constructeur :
@Injectable()
export class ApplicationsService {
constructor(private readonly db: PrismaService) {}
}
Remplace PrismaService par un mock sans toucher au service. C'est ce qui rend les tests sains.
Les guards tournent avant un handler et décident autoriser ou refuser — l'authentification, le cadrage de tenant, les rôles vivent tous ici :
@UseGuards(JwtAuthGuard, RolesGuard)
@Roles("admin")
@Get("applications")
Les intercepteurs enveloppent requête/réponse pour un comportement transversal sans toucher à chaque contrôleur. Les pipes transforment et valident l'entrée avant qu'elle n'atteigne un handler. Les filtres d'exception façonnent les erreurs levées en réponses HTTP cohérentes sur toute l'API.
Je sépare core/ (l'infrastructure dont beaucoup de modules dépendent mais qui n'est pas elle-même une fonctionnalité — auth, le client de base, e-mail, stockage, le processeur d'outbox, la résolution des paramètres, la passerelle temps réel) de modules/ (les vrais domaines métier). Ça rend évident où appartient une nouvelle question : « comment on parle à S3 » est du core, « quel est le flux de statut d'une candidature » est un module.
Le compromis est une vraie courbe d'apprentissage et plus de boilerplate par fonctionnalité qu'une route Express minimale. Pour quelque chose qui grossit jusqu'à des dizaines de modules, cette structure d'entrée se rentabilise — c'est vraiment dur de faire un bazar dans NestJS, parce que le framework te ramène sans cesse vers les modules et les services même sous pression d'échéance.