Pourquoi votre projet a-t-il besoin d'un API Gateway en JavaScript ?
\n\nImaginez que votre backend soit un immense centre commercial. À l'intérieur, des dizaines de magasins (microservices) : l'un vend des livres, un autre des vêtements, un troisième de l'électronique. Chaque magasin a sa propre entrée, ses propres règles et son propre langage. Imaginez maintenant qu'un visiteur (l'application cliente) doive passer par toutes ces entrées pour acheter un simple t-shirt. Le chaos, n'est-ce pas ?
\n\nDans le monde du développement web, ce problème est résolu par l'API Gateway – un point d'entrée unique pour tous les microservices. Il agit comme un administrateur de centre commercial : il oriente les requêtes, vérifie les billets (tokens), collecte les données des différents magasins et renvoie une réponse prête au client. Aujourd'hui, nous allons voir comment écrire une telle passerelle en JavaScript pur avec Node.js.
\n\nCet article sera utile aussi bien aux débutants qui découvrent l'architecture des microservices qu'aux développeurs expérimentés souhaitant voir des exemples de code fonctionnels. C'est parti !
\n\nQu'est-ce qu'un API Gateway et pourquoi en avez-vous besoin ?
\n\nL'API Gateway est un composant serveur qui agit comme une couche intermédiaire entre le client et les services internes. Il prend en charge :
\n- \n
- Le routage – il dirige les requêtes vers le microservice approprié. \n
- L'authentification et l'autorisation – il vérifie si l'utilisateur a accès. \n
- L'agrégation des données – il rassemble les réponses de plusieurs services en une seule. \n
- La limitation des requêtes – il protège le backend contre les surcharges. \n
- La transformation des protocoles – par exemple, il convertit REST en GraphQL. \n
Pour les services JavaScript (notamment sur Node.js), l'API Gateway est un choix naturel. Il s'écrit facilement avec Express, Koa ou Fastify, et surtout, il permet de conserver un style de code uniforme dans tout le projet.
\n\nConception de la structure de l'API Gateway sur Node.js
\n\nAvant d'écrire du code, définissons l'architecture. Supposons que nous ayons trois microservices :
\n- \n
users-service– gestion des utilisateurs (port 3001). \n orders-service– commandes (port 3002). \n products-service– catalogue de produits (port 3003). \n
Le client (frontend) s'adresse uniquement au Gateway sur le port 8080. Le Gateway décide lui-même où diriger la requête.
\n\nÉtape 1. Configuration de base d'Express
\n\nCréons un nouveau projet et installons les dépendances :
\nmkdir api-gateway\ncd api-gateway\nnpm init -y\nnpm install express http-proxy-middleware dotenv\n\nÉcrivons maintenant un Gateway simple qui proxy les requêtes vers les services :
\n// gateway.js\nconst express = require('express');\nconst { createProxyMiddleware } = require('http-proxy-middleware');\nrequire('dotenv').config();\n\nconst app = express();\nconst PORT = process.env.PORT || 8080;\n\n// Routes pour les microservices\napp.use('/users', createProxyMiddleware({\n target: 'http://localhost:3001',\n changeOrigin: true,\n}));\n\napp.use('/orders', createProxyMiddleware({\n target: 'http://localhost:3002',\n changeOrigin: true,\n}));\n\napp.use('/products', createProxyMiddleware({\n target: 'http://localhost:3003',\n changeOrigin: true,\n}));\n\napp.listen(PORT, () => {\n console.log(`API Gateway démarré sur le port ${PORT}`);\n});\n\nEt voilà ! Désormais, toute requête vers /users est automatiquement redirigée vers users-service. Mais ce n'est que le début. Un vrai Gateway doit faire plus.
Ajout de l'authentification et de la vérification des tokens
\n\nL'une des tâches principales de l'API Gateway est l'authentification centralisée. Au lieu de vérifier le JWT dans chaque microservice, nous le faisons une seule fois dans la passerelle.
\n\nAjoutons un middleware pour vérifier le token :
\n// middleware/auth.js\nconst jwt = require('jsonwebtoken');\n\nconst authMiddleware = (req, res, next) =>