حالات تطبيقية في Node.js

Contexte : Une application doit utiliser un port configurable selon l'environnement. Le Problème : Le port est codé en dur dans l'application. Contraintes : Utiliser process.env pour la configuration. Livrable attendu : Modifier l'application pour utiliser une variable d'environnement avec valeur par défaut si non définie.

Contexte : Le serveur Node.js échoue au démarrage avec une erreur EADDRINUSE. Le Problème : Le port configuré est déjà occupé. Contraintes : Gérer l'erreur proprement au démarrage. Livrable attendu : Ajouter une gestion d'erreur sur le serveur afin d'afficher un message explicite si le port est indisponible.

Contexte : Une API interne doit renvoyer des données JSON à un front-end. Le Problème : Le serveur renvoie du texte brut au lieu d'un JSON valide. Code actuel : res.write({ message: "OK" }); res.end(); Contraintes : Respecter les headers HTTP appropriés. Livrable attendu : Corriger l'implémentation pour renvoyer un JSON valide avec le header Content-Type correctement défini.

Contexte : Vous démarrez un microservice interne pour exposer quelques endpoints simples. Le Problème : Aucun serveur Node.js n'est encore configuré pour répondre aux requêtes HTTP. Contraintes : Utiliser Node.js natif avec le module http. Aucun framework externe comme Express. Livrable attendu : Implémenter un serveur HTTP capable de répondre sur deux routes (/ et /health) avec des réponses JSON simples et un code de statut approprié.

Contexte : Une API doit recevoir des données JSON envoyées par un client. Le Problème : Les données du body ne sont pas accessibles. Code actuel : app.post('/user', (req, res) => { console.log(req.body); res.send('ok'); }); Contraintes : Utiliser express.json(). Livrable attendu : Configurer correctement Express pour parser le body JSON et retourner les données reçues.

Contexte : Une route API doit accepter un paramètre name en query string. Le Problème : La valeur transmise n'est pas correctement récupérée. Contraintes : Utiliser Express et req.query. Livrable attendu : Implémenter une route GET capable de lire le paramètre name et de retourner un message personnalisé en JSON.

Contexte : Une API Express doit logger toutes les requêtes entrantes. Le Problème : Aucun mécanisme centralisé de logging n'est présent. Contraintes : Utiliser Express sans librairie de logging externe. Livrable attendu : Ajouter un middleware global affichant la méthode et l'URL de chaque requête.

Contexte : Les routes inexistantes renvoient une réponse par défaut peu explicite. Le Problème : Aucune gestion personnalisée des erreurs 404 n'est configurée. Contraintes : Ajouter un middleware en fin de chaîne. Livrable attendu : Implémenter une gestion 404 retournant un message JSON clair lorsque la route n'existe pas.

Contexte : Une application doit lire un fichier de configuration local au démarrage. Le Problème : Aucune gestion d'erreur n'est prévue si le fichier n'existe pas. Contraintes : Utiliser le module fs natif en version asynchrone. Livrable attendu : Implémenter la lecture d'un fichier avec gestion propre des erreurs et affichage d'un message explicite en cas d'échec.

Contexte : Une fonction utilise des promesses avec .then() imbriqués. Le Problème : Le code devient difficile à lire et à maintenir. Contraintes : Refactoriser avec async/await. Livrable attendu : Transformer une fonction basée sur .then() en version async/await plus lisible tout en conservant la gestion d'erreur.

Contexte : Vous reprenez une API Node.js dont toute la logique est écrite dans un seul fichier server.js. Le Problème : Les routes, la logique métier et la configuration sont mélangées, rendant le projet difficile à maintenir. Contraintes : Utiliser Express. Mettre en place une séparation claire entre routes, contrôleurs et configuration sans modifier le comportement métier. Livrable attendu : Refactoriser l'application en architecture modulaire avec dossiers routes, controllers et éventuellement services, tout en gardant une structure scalable.

Contexte : Une API doit se connecter à MongoDB au démarrage. Le Problème : En cas d'échec de connexion, le serveur continue à tourner sans accès base de données. Contraintes : Utiliser mongoose avec gestion propre des erreurs de connexion. Livrable attendu : Implémenter une logique empêchant le démarrage complet du serveur si la connexion à la base échoue.

Contexte : Une fonction asynchrone appelle une promesse mais ne la retourne pas. Le Problème : Les réponses sont envoyées avant la fin du traitement. Code actuel : app.get('/data', (req, res) => { fetchData().then(data => { res.json(data); }); }); Contraintes : Garantir l'attente correcte du résultat. Livrable attendu : Refactoriser la route avec async/await ou retour explicite de promesse pour assurer la bonne séquence d'exécution.

Contexte : Plusieurs routes asynchrones utilisent async/await sans gestion d'erreur centralisée. Le Problème : Les erreurs non capturées provoquent des crashs serveur. Contraintes : Implémenter un wrapper pour les fonctions async afin de transmettre les erreurs au middleware global. Livrable attendu : Mettre en place un système évitant la répétition de try/catch dans chaque route et garantissant une gestion d'erreur propre.

Contexte : Une API Express gère les erreurs directement dans chaque route. Le Problème : Les réponses d'erreur sont incohérentes et dupliquées. Contraintes : Mettre en place un middleware centralisé de gestion des erreurs. Livrable attendu : Implémenter un error-handling middleware capturant les exceptions et renvoyant des réponses JSON structurées avec code HTTP approprié.

Contexte : Une API publique subit des abus avec trop de requêtes par seconde. Le Problème : Aucun mécanisme ne limite la fréquence des appels. Contraintes : Utiliser un middleware comme express-rate-limit. Livrable attendu : Mettre en place un système limitant le nombre de requêtes par IP sur une période définie.

Contexte : Une API doit accepter l'upload d'images utilisateur. Le Problème : Aucun contrôle de type ou taille n'est en place. Contraintes : Utiliser multer avec validation. Livrable attendu : Mettre en place un endpoint d'upload sécurisé limitant la taille et validant le type MIME.

Contexte : Une API doit protéger certaines routes accessibles uniquement aux utilisateurs authentifiés. Le Problème : Aucun mécanisme d'authentification n'est implémenté. Contraintes : Utiliser jsonwebtoken et middleware Express. Livrable attendu : Mettre en place une génération de token JWT lors du login et un middleware vérifiant la validité du token sur les routes protégées.

Contexte : Une route effectue un calcul coûteux à chaque requête. Le Problème : Le temps de réponse est élevé pour des données rarement modifiées. Contraintes : Implémenter un cache mémoire simple (Map ou node-cache). Livrable attendu : Ajouter un mécanisme de cache réduisant les calculs redondants et améliorant la latence.

Contexte : Les logs actuels utilisent uniquement console.log. Le Problème : Les logs sont difficiles à exploiter en production. Contraintes : Utiliser une librairie comme winston ou pino. Livrable attendu : Implémenter un système de logs structuré avec niveaux (info, warn, error) et format JSON adapté à un environnement production.

Contexte : Une API reçoit des requêtes répétitives sur des données peu modifiées. Le Problème : Les accès base de données saturent sous charge. Contraintes : Intégrer Redis pour cache distribué avec gestion d'invalidation. Livrable attendu : Implémenter une stratégie de cache performante incluant TTL, invalidation ciblée et fallback base de données.

Contexte : Votre application monolithique Node.js commence à atteindre ses limites en termes de scalabilité et de maintenance. Le Problème : Toutes les fonctionnalités (auth, paiement, catalogue) sont regroupées dans un seul service, compliquant les déploiements et la montée en charge. Contraintes : Concevoir une architecture microservices avec séparation claire des domaines. Implémenter une API Gateway centralisant l'authentification et le routage. Livrable attendu : Proposer une architecture détaillée incluant découpage des services, communication inter-services (HTTP ou message broker) et stratégie de déploiement scalable.

Contexte : Une API Node.js utilise JWT mais ne gère pas correctement l'expiration des tokens. Le Problème : Les utilisateurs doivent se reconnecter fréquemment et aucun mécanisme de rotation de refresh token n'est en place. Contraintes : Implémenter access token court et refresh token sécurisé stocké côté serveur. Livrable attendu : Mettre en place une stratégie complète incluant génération, stockage sécurisé, rotation et invalidation des refresh tokens.

Contexte : L'application est déployée sur plusieurs instances. Le Problème : Les logs sont dispersés et difficiles à analyser. Contraintes : Intégrer une solution centralisée (ELK ou équivalent) et logs structurés. Livrable attendu : Concevoir une architecture de logging centralisée facilitant le monitoring, le debug et l'analyse des incidents.

Contexte : Certaines tâches lourdes (emails, traitement d'images) ralentissent les requêtes HTTP. Le Problème : Les opérations sont exécutées synchroniquement, impactant la performance. Contraintes : Utiliser un système de queue (Bull ou RabbitMQ) avec stratégie de retry automatique. Livrable attendu : Concevoir un système de traitement asynchrone déportant les tâches lourdes hors du cycle HTTP et gérant les échecs proprement.

Contexte : Une application temps réel (chat, notifications) doit supporter des milliers de connexions simultanées. Le Problème : Le serveur unique ne supporte pas la montée en charge. Contraintes : Utiliser socket.io avec Redis adapter pour synchronisation multi-instances. Livrable attendu : Concevoir une architecture WebSocket scalable permettant synchronisation entre instances Node.js.

Contexte : Une API gère des opérations financières nécessitant cohérence et atomicité. Le Problème : Les opérations partiellement échouées provoquent des incohérences. Contraintes : Utiliser transactions base de données et gestion d'erreurs robuste. Livrable attendu : Concevoir un système transactionnel garantissant l'atomicité et la cohérence des opérations critiques.

Contexte : Une API subit une forte charge sur un seul processus Node.js. Le Problème : L'application n'exploite pas pleinement les cœurs CPU disponibles. Contraintes : Utiliser le module cluster natif ou PM2 en mode cluster. Livrable attendu : Mettre en place une architecture exploitant plusieurs processus Node.js avec répartition de charge efficace.

Contexte : Une application Node.js a évolué sans structure claire et devient difficile à maintenir. Le Problème : Couplage fort entre routes, logique métier et accès données. Contraintes : Appliquer principes Clean Architecture et séparation des couches. Livrable attendu : Proposer une architecture enterprise-ready séparant clairement contrôleurs, use cases, entités et infrastructures pour améliorer maintenabilité et testabilité.

Contexte : Une API publique est exposée sur Internet. Le Problème : Elle est vulnérable aux attaques XSS, injection et brute force. Contraintes : Implémenter helmet, rate limiting, validation stricte et sanitation des entrées. Livrable attendu : Mettre en place une couche de sécurité complète protégeant l'API contre les principales menaces web.