## Quand l’IA écrit du NestJS, elle casse vos patterns (et comment l’en empêcher) Vous avez déjà demandé à Claude ou GitHub Copilot de générer un module NestJS ? Si oui, vous savez que le résultat ressemble souvent à un plat de spaghetti architectural : des services qui importent directement des repositories d’autres modules, des DTOs oubliés, des interceptors ignorés. Le problème n’est pas l’IA — c’est l’absence de règles explicites pour un framework qui, malgré son opinionated design, laisse trop de liberté dans l’implémentation. La solution ? Un **CLAUDE.md** (ou équivalent pour votre outil d’IA préféré). Ce fichier de configuration force l’IA à respecter vos conventions NestJS, comme le montre l’expérience d’une équipe qui a réduit ses incohérences de 80% en adoptant 13 règles simples. Parmi les plus critiques : - **Un module = une feature**. Pas d’imports croisés entre modules — tout passe par les exports. Les utilitaires partagés ? Un `SharedModule` dédié. - **Validation globale**. Tous les DTOs utilisent `class-validator`, et le `ValidationPipe` est activé au niveau global avec `whitelist: true` pour rejeter les champs non déclarés. - **Pas de `req.body` brut**. Jamais. Même pour les endpoints de test. ```typescript // main.ts app.useGlobalPipes( new ValidationPipe({ whitelist: true, forbidNonWhitelisted: true, transform: true, }) ); ``` Pourquoi ça marche ? Parce que NestJS est conçu pour être modulaire, mais sans garde-fous, même les développeurs expérimentés (et les IA) finissent par contourner les bonnes pratiques. Un `CLAUDE.md` agit comme un contrat architectural : il documente les attentes implicites du projet et les rend explicites pour les humains *et* les machines. --- ## Le boilerplate NestJS est mort, vive les générateurs de microservices Créer un nouveau microservice NestJS en 2025 devrait prendre 30 minutes, pas 2 jours. Pourtant, la plupart des équipes perdent encore des heures à configurer Docker, Prisma, Kafka, et les logs avant d’écrire une seule ligne de logique métier. Le constat est brutal : **le boilerplate tue la productivité**, surtout quand on sait que 80% des microservices partagent la même stack technique. La réponse ? Des outils comme **Candy-Nest-CLI**, qui automatisent la génération d’un squelette complet de microservice. En une commande, vous obtenez : - Un `docker-compose.yml` préconfiguré pour PostgreSQL, Redis, et Kafka. - Une intégration prête à l’emploi avec Prisma ou TypeORM. - Des logs structurés avec Winston ou Pino. - Un système de health checks et de métriques. - Un pipeline CI/CD basique avec GitHub Actions. ```bash npx candy-nest-cli generate --name=payments --db=prisma --broker=kafka ``` L’impact est immédiat : les développeurs passent moins de temps à copier-coller des configs et plus de temps à résoudre des problèmes métiers. Et contrairement aux templates statiques, ces générateurs évoluent avec votre stack. Besoin d’ajouter OpenTelemetry ? Une option `--metrics=otel` suffit. Mais attention : l’automatisation ne doit pas devenir une boîte noire. Les équipes qui adoptent ces outils avec succès suivent deux règles : 1. **Versionner les templates**. Un générateur doit être un dépôt Git comme les autres, avec des PRs et des revues de code. 2. **Documenter les exceptions**. Si un service nécessite une configuration spéciale (ex : un broker RabbitMQ au lieu de Kafka), le générateur doit le signaler clairement. --- ## La standardisation des réponses API : le pattern qui sauve vos frontend Imaginez : votre frontend appelle `/users` et reçoit `{ success: true, data: [...] }`, mais `/products` retourne directement un tableau `[{...}, {...}]`. Puis `/orders` lève une erreur avec un message en string brut. Résultat ? Votre équipe frontend passe plus de temps à normaliser les réponses qu’à développer des features. Ce cauchemar est la norme dans 90% des APIs NestJS. Pourtant, la solution existe depuis des années : **un wrapper de réponse standardisé**. Des bibliothèques comme `nestjs-api-forge` transforment ce problème en deux lignes de code : ```typescript // app.module.ts import { ApiForgeModule } from 'nestjs-api-forge'; @Module({ imports: [ApiForgeModule.forRoot()], }) export class AppModule {} ``` Désormais, *toutes* les réponses suivent le même format : ```json { "success": true, "statusCode": 200, "message": "Users retrieved successfully", "data": [{...}], "timestamp": "2025-04-05T12:00:00.000Z" } ``` Les erreurs ? Structurées de la même manière, avec des détails de validation au niveau des champs : ```json { "success": false, "statusCode": 400, "message": "Validation failed", "errors": [ { "property": "email", "constraints": { "isEmail": "email must be an email" } } ] } ``` L’avantage ? Plus de surprises pour le frontend. Plus de `try/catch` alambiqués pour gérer des erreurs hétérogènes. Et surtout, une documentation Swagger qui reflète *réellement* ce que l’API retourne. Mais le vrai gain est ailleurs : **la maintenabilité**. Quand une nouvelle équipe rejoint le projet, elle sait immédiatement à quoi s’attendre. Quand un bug survient, les logs sont cohérents. Et quand vous devez migrer vers une nouvelle stack frontend (React → Svelte, par exemple), la couche API reste stable. --- ## CRUD générique : comment j’ai supprimé 60% de mon code répétitif Si vous utilisez Prisma avec NestJS, vous avez probablement écrit ce code des dizaines de fois : ```typescript // user.service.ts async getAll(): Promise { return this.prisma.user.findMany({ where: { deletedAt: null } }); } async getById(id: string): Promise { const user = await this.prisma.user.findUnique({ where: { id } }); if (!user) throw new NotFoundException('User not found'); return user; } ``` Multipliez ça par 10 modules, et vous obtenez des centaines de lignes de code répétitif. La solution ? **Un `BaseService` et un `BaseRepository` génériques** qui encapsulent la logique CRUD commune. Voici comment ça marche : 1. **Définir un `BaseRepository`** qui gère les opérations de base (avec soft delete par défaut) : ```typescript // base.repository.ts @Injectable() export class BaseRepository { constructor(private readonly prisma: PrismaService) {} async findAll(): Promise { return this.prisma[this.modelName].findMany({ where: { deletedAt: null } }); } async findById(id: string): Promise { const record = await this.prisma[this.modelName].findUnique({ where: { id } }); if (!record) throw new NotFoundException(`${this.modelName} not found`); return record; } } ``` 2. **Créer un `BaseService`** qui utilise le repository : ```typescript // base.service.ts @Injectable() export class BaseService { constructor(private readonly repository: BaseRepository) {} async getAll(): Promise { return this.repository.findAll(); } async getById(id: string): Promise { return this.repository.findById(id); } } ``` 3. **Étendre ces classes dans vos services** : ```typescript // user.service.ts @Injectable() export class UserService extends BaseService { constructor(repository: UserRepository) { super(repository); } } ``` Résultat ? Plus de duplication. Une logique métier centralisée. Et surtout, des bugs corrigés une seule fois (ex : ajouter un filtre `deletedAt: null` partout). Mais attention aux pièges : - **Ne pas tout abstraire**. Si un endpoint nécessite une logique spécifique (ex : un `getByEmail`), ne forcez pas l’abstraction. - **Documenter les conventions**. Par exemple, préciser que `findAll` inclut toujours un soft delete. - **Tester les cas limites**. Un `BaseService` mal conçu peut cacher des bugs subtils (ex : une transaction qui ne s’applique pas à toutes les méthodes). --- ## Ce que les attaques DDoS révèlent sur votre architecture NestJS Quand un développeur voit son API NestJS subir 27 000 requêtes malveillantes en quelques heures, deux réactions sont possibles : 1. **Paniquer** et ajouter des rate limiters en urgence. 2. **Profiter de l’occasion** pour renforcer l’architecture. La deuxième option est la bonne. Voici ce qu’une attaque révèle sur votre stack NestJS : ### 1. Votre base de données est le maillon faible Dans l’attaque mentionnée, le troll a exploité un endpoint non protégé pour inonder la base de données de faux enregistrements. La solution ? **Protéger les endpoints sensibles avec des guards et des rate limiters**, mais aussi : - **Utiliser des bases de données serverless** comme NeonDB, qui scale automatiquement et limite les dégâts. - **Isoler les opérations critiques** dans des transactions avec des timeouts stricts. - **Ajouter des validations côté base** (ex : triggers pour bloquer les inserts en masse). ```typescript // rate-limiter.guard.ts @Injectable() export class RateLimiterGuard implements CanActivate { constructor(private readonly limiter: RateLimiterRedis) {} async canActivate(context: ExecutionContext): Promise { const request = context.switchToHttp().getRequest(); const key = request.ip; try { await this.limiter.consume(key); return true; } catch { throw new ThrottlerException(); } } } ``` ### 2. Vos logs sont inutiles en cas de crise Si vos logs ressemblent à ça : ``` [2025-04-05T12:00:00.000Z] INFO: Request received [2025-04-05T12:00:00.010Z] INFO: User not found ``` Vous êtes dans le noir. **Des logs structurés et contextuels** sont indispensables : ``` { "timestamp": "2025-04-05T12:00:00.000Z", "level": "WARN", "message": "Rate limit exceeded", "context": { "ip": "192.168.1.1", "endpoint": "/api/users", "userId": "abc123", "requestId": "req-456" } } ``` Avec des outils comme **Winston** ou **Pino**, vous pouvez filtrer, agréger, et corréler les logs en temps réel. ### 3. Votre architecture n’est pas résiliente par défaut Une attaque DDoS révèle souvent des faiblesses structurelles : - **Pas de circuit breakers** : une base de données saturée fait tomber tout le service. - **Pas de retry policies** : les requêtes échouent au premier obstacle. - **Pas de bulkheading** : un endpoint lent bloque les autres. La solution ? Intégrer **resilience4j** ou **Polly** dans votre stack NestJS : ```typescript // resilience.module.ts @Module({ providers: [ { provide: 'USER_SERVICE', useFactory: () => { const retry = new Retry('userService', { maxAttempts: 3, delay: 100, }); return retry.decorate(userService); }, }, ], }) export class ResilienceModule {} ``` --- ## Conclusion : NestJS en 2025, c’est l’équilibre entre structure et flexibilité NestJS a toujours été un framework opinionated, mais en 2025, cette opinionatedness devient *explicite*. Les équipes qui réussissent ne se contentent plus de suivre les bonnes pratiques — elles les **automatisent**, les **standardisent**, et les **renforcent**. Voici les trois tendances à adopter dès maintenant : 1. **Automatisez le boilerplate** avec des générateurs comme Candy-Nest-CLI. Votre temps est précieux : ne le gaspillez pas à configurer Docker. 2. **Standardisez vos réponses API** avec des wrappers comme `nestjs-api-forge`. Un frontend heureux est un frontend qui n’a pas à deviner vos formats. 3. **Abstrayez le CRUD répétitif** avec des `BaseService` et `BaseRepository`. Moins de code = moins de bugs. Et surtout, **préparez-vous aux attaques**. Une architecture NestJS moderne n’est pas seulement élégante — elle est résiliente. Des logs structurés, des rate limiters, et des circuit breakers devraient faire partie de votre stack par défaut. NestJS en 2025, c’est l’art de concilier la rigueur d’un framework structuré avec l’agilité nécessaire pour innover. Le choix est simple : soit vous subissez les évolutions, soit vous les anticipez.

NestJS en 2025 : pourquoi l'opinionated devient la nouvelle norme

Points clés

Sources