Cas pratiques NestJS

Contexte : L'application doit utiliser un port configurable selon l'environnement. Le Problème : Le port est codé en dur dans le bootstrap. Contraintes : Utiliser @nestjs/config. Livrable attendu : Configurer le ConfigModule et utiliser une variable d'environnement pour définir le port avec valeur par défaut.

Contexte : Un controller a été créé mais NestJS ne le reconnaît pas. Le Problème : Le controller n'est pas déclaré dans le module. Contraintes : Vérifier la configuration du module. Livrable attendu : Corriger le module afin d'enregistrer correctement le controller et permettre son utilisation.

Contexte : Vous démarrez une nouvelle API backend avec NestJS pour un projet interne. Le Problème : Aucun endpoint n'est encore exposé et l'équipe a besoin d'une route simple pour valider l'infrastructure. Contraintes : Utiliser la CLI NestJS standard. Créer un module et un controller sans dépendances externes. Livrable attendu : Implémenter un controller avec une route GET /health retournant un JSON { "status": "ok" } avec code HTTP 200.

Contexte : Une API doit recevoir des données JSON pour créer une ressource. Le Problème : Aucun DTO n'est utilisé pour structurer les données entrantes. Contraintes : Créer un DTO TypeScript simple et l'utiliser dans le controller. Livrable attendu : Implémenter une route POST /users utilisant un DTO pour typer les données reçues.

Contexte : Une route doit retourner une erreur spécifique si une ressource est introuvable. Le Problème : Les erreurs sont renvoyées de manière générique. Contraintes : Utiliser HttpException ou NotFoundException. Livrable attendu : Implémenter une gestion d'erreur renvoyant un statut 404 avec message personnalisé lorsque la ressource n'existe pas.

Contexte : Une API doit récupérer une ressource par identifiant. Le Problème : Le paramètre d'URL n'est pas correctement exploité. Contraintes : Utiliser @Param() pour récupérer l'identifiant. Livrable attendu : Implémenter une route GET /users/:id retournant l'id fourni dans l'URL sous forme JSON.

Contexte : L'équipe souhaite logger toutes les requêtes entrantes. Le Problème : Aucun middleware global n'est configuré. Contraintes : Créer un middleware conforme à l'interface NestMiddleware. Livrable attendu : Implémenter un middleware affichant la méthode HTTP et l'URL de chaque requête.

Contexte : Une logique métier simple doit être extraite du contrôleur pour respecter les bonnes pratiques NestJS. Le Problème : Toute la logique est actuellement dans le controller. Contraintes : Créer un service injectable via @Injectable() et l'injecter via le constructeur. Livrable attendu : Refactoriser le controller pour déléguer la logique à un service séparé correctement injecté.

Contexte : Une route POST reçoit des données sans validation. Le Problème : Des données invalides sont acceptées par l'API. Contraintes : Utiliser class-validator et ValidationPipe. Livrable attendu : Ajouter un DTO validé avec décorateurs (@IsString, @IsEmail, etc.) et activer la validation globale.

Contexte : Une route doit accepter un paramètre optionnel en query string. Le Problème : Les paramètres ne sont pas correctement récupérés. Contraintes : Utiliser @Query() dans le controller. Livrable attendu : Implémenter une route GET /search récupérant un paramètre query et le retournant en JSON.

Contexte : Votre application NestJS commence à grandir et toutes les fonctionnalités sont regroupées dans AppModule. Le Problème : La structure devient difficile à maintenir et les dépendances sont mal organisées. Contraintes : Organiser l'application par modules métier (UsersModule, AuthModule, OrdersModule) avec export/import appropriés. Livrable attendu : Refactoriser l'application en architecture modulaire claire, avec séparation des responsabilités et injection propre des services entre modules.

Contexte : L'API doit être accessible uniquement depuis certaines applications front-end. Le Problème : CORS est actuellement activé pour toutes les origines. Contraintes : Configurer CORS dynamiquement via variables d'environnement. Livrable attendu : Mettre en place une configuration CORS sécurisée limitant l'accès aux origines autorisées.

Contexte : Une application doit persister ses données dans une base relationnelle. Le Problème : La configuration actuelle ne gère pas correctement les erreurs de connexion. Contraintes : Utiliser TypeORM avec configuration via ConfigModule. Livrable attendu : Mettre en place une connexion base de données fiable avec gestion d'erreurs et entités correctement définies.

Contexte : Les erreurs sont renvoyées de manière incohérente selon les controllers. Le Problème : Aucune structure uniforme des réponses d'erreur n'est définie. Contraintes : Implémenter un ExceptionFilter global. Livrable attendu : Créer un filtre d'exception personnalisé garantissant un format JSON standardisé pour toutes les erreurs de l'application.

Contexte : Certaines routes effectuent des calculs coûteux répétitifs. Le Problème : Les performances se dégradent sous charge. Contraintes : Utiliser CacheModule de NestJS. Livrable attendu : Mettre en place un cache avec TTL pour améliorer les performances des endpoints critiques.

Contexte : L'équipe souhaite tracer les requêtes et réponses de manière uniforme. Le Problème : Les logs sont dispersés et incohérents. Contraintes : Utiliser un Interceptor global pour logger méthode, durée et statut. Livrable attendu : Développer un interceptor mesurant le temps d'exécution des requêtes et générant des logs structurés.

Contexte : Une API multi-utilisateurs doit restreindre certaines routes selon les rôles (admin, user). Le Problème : Les contrôles d'accès sont absents ou dispersés. Contraintes : Créer un décorateur personnalisé et un RolesGuard. Livrable attendu : Mettre en place un système RBAC complet permettant de protéger dynamiquement les routes selon le rôle utilisateur.

Contexte : Une API NestJS doit protéger certaines routes accessibles uniquement aux utilisateurs authentifiés. Le Problème : Aucun mécanisme de vérification de token n'est en place. Contraintes : Utiliser @nestjs/jwt et créer un AuthGuard personnalisé. Livrable attendu : Mettre en place un système complet d'authentification avec génération de JWT et Guard protégeant les routes privées.

Contexte : Certaines opérations longues ne doivent pas bloquer les requêtes HTTP. Le Problème : Les traitements sont exécutés directement dans les controllers. Contraintes : Intégrer BullModule pour gérer des jobs asynchrones. Livrable attendu : Configurer une queue Bull permettant d'exécuter des tâches lourdes en arrière-plan.

Contexte : Certaines routes nécessitent une validation spécifique dépassant les décorateurs standards. Le Problème : La validation actuelle ne couvre pas certaines règles métier. Contraintes : Créer un Pipe personnalisé implémentant PipeTransform. Livrable attendu : Développer un pipe validant ou transformant dynamiquement les données entrantes selon des règles métier spécifiques.

Contexte : Une application monolithique doit évoluer vers une architecture distribuée. Le Problème : Les modules sont fortement couplés et déployés ensemble. Contraintes : Utiliser les microservices NestJS avec RabbitMQ ou Kafka. Livrable attendu : Concevoir une architecture microservices incluant communication asynchrone, gestion des événements et découplage complet des domaines métier.

Contexte : Une application SaaS doit gérer plusieurs organisations avec des rôles complexes. Le Problème : Les règles d'autorisation actuelles sont statiques et insuffisantes. Contraintes : Implémenter un système RBAC/ABAC dynamique avec Guards et décorateurs personnalisés. Livrable attendu : Concevoir un moteur d'autorisation flexible capable de gérer multi-tenant, rôles hiérarchiques et permissions dynamiques.

Contexte : Votre application NestJS a évolué rapidement et mélange contrôleurs, logique métier et accès base de données. Le Problème : Le couplage fort rend les tests complexes et limite l'évolutivité du système. Contraintes : Appliquer une architecture hexagonale (ports & adapters) avec séparation claire entre domaine, application et infrastructure. Livrable attendu : Proposer une architecture complète séparant entités métier, use cases, interfaces de repository et implémentations techniques, garantissant testabilité et indépendance des frameworks.

Contexte : Une API sécurisée nécessite un mécanisme robuste d'authentification longue durée. Le Problème : Les refresh tokens actuels ne sont ni rotatifs ni invalidables. Contraintes : Implémenter access token court, refresh token stocké en base et rotation automatique avec invalidation. Livrable attendu : Concevoir un système complet garantissant sécurité renforcée, gestion des sessions et révocation des tokens compromis.

Contexte : L'application est déployée sur plusieurs instances en production. Le Problème : Les erreurs et lenteurs sont difficiles à tracer à travers les services. Contraintes : Intégrer OpenTelemetry ou équivalent pour tracing distribué. Livrable attendu : Mettre en place un système d'observabilité complet incluant logs structurés, métriques et tracing inter-services.

Contexte : Une application temps réel doit supporter plusieurs milliers de connexions simultanées. Le Problème : En environnement multi-instance, les événements ne sont pas synchronisés. Contraintes : Utiliser l'adaptateur Redis pour WebSockets NestJS. Livrable attendu : Concevoir une architecture WebSocket scalable synchronisant les messages entre instances via Redis.

Contexte : Une API publique doit répondre à des exigences de sécurité élevées. Le Problème : La configuration actuelle ne couvre pas toutes les menaces (injection, XSS, brute force). Contraintes : Intégrer validation stricte, rate limiting, helmet, et sécurisation des headers. Livrable attendu : Mettre en place une stratégie complète de sécurisation alignée avec les recommandations OWASP.

Contexte : Plusieurs services doivent effectuer des opérations coordonnées sur différentes bases de données. Le Problème : En cas d'échec intermédiaire, l'état global devient incohérent. Contraintes : Implémenter un pattern Saga ou compensation transactionnelle. Livrable attendu : Concevoir une stratégie garantissant cohérence globale via orchestration ou choreography des transactions distribuées.

Contexte : L'application subit une forte charge sur certains endpoints critiques. Le Problème : Les requêtes base de données deviennent un goulot d'étranglement. Contraintes : Intégrer CacheModule avec Redis et stratégie d'invalidation fine. Livrable attendu : Concevoir un système de cache distribué performant garantissant cohérence et réduction significative de latence.

Contexte : L'application doit être déployée sur une infrastructure cloud avec autoscaling. Le Problème : L'architecture actuelle dépend d'états locaux et n'est pas prête pour la scalabilité horizontale. Contraintes : Rendre l'application stateless et compatible Docker. Livrable attendu : Proposer une architecture cloud-native adaptée au déploiement scalable avec gestion des variables d'environnement et services externes.