API Gateway

Comment centraliser l'accès à vos microservices grâce à un point d'entrée unique qui gère le routage, l'authentification, le rate limiting et la transformation des réponses.

Quel problème résout-il

Dans une architecture de microservices, les clients (web, mobile, IoT) doivent communiquer avec plusieurs services backend. Sans un point d’entrée centralisé, chaque client doit :

• Connaître les adresses de tous les services
• Gérer l’authentification avec chaque service individuellement
• Composer avec des protocoles et des formats de réponse différents
• Implémenter par ses propres moyens la logique de reprises (retries), de timeouts et de circuit breaking

Sans API Gateway :
  Mobile App → Service Utilisateurs (auth + données)
  Mobile App → Service Produits (auth + données)
  Mobile App → Service Commandes (auth + données)
  Mobile App → Service Paiements (auth + données)
  
  Chaque client connaît N services
  Chaque service implémente auth, rate limiting, CORS...

Cela génère un couplage direct entre les clients et les services internes, complique l’évolution indépendante des services et duplique les préoccupations transversales (cross-cutting concerns) dans chaque microservice.

Comment ça fonctionne

L’API Gateway agit comme un reverse proxy qui se place entre les clients et les microservices. Toutes les requêtes externes passent par lui, et la gateway se charge de les router vers le service adéquat.

Avec API Gateway :
  Mobile App  ─┐
  Web App     ─┤──► API Gateway ──► Service Utilisateurs
  IoT Device  ─┘         │──► Service Produits
                          │──► Service Commandes
                          └──► Service Paiements
  
  Un seul point d'entrée
  Cross-cutting concerns centralisés

Responsabilités principales

Flux typique d’une requête

1. Le client envoie : GET /api/products/123
2. La gateway reçoit la requête
3. La gateway valide le token JWT → ✅ valide
4. La gateway vérifie le rate limit → ✅ dans la limite
5. La gateway route vers Product Service : GET /products/123
6. Product Service répond avec les données du produit
7. La gateway transforme la réponse (si nécessaire)
8. La gateway enregistre les métriques (latence, status code)
9. La gateway renvoie la réponse au client

Modèles de composition

L’API Gateway peut mettre en œuvre différentes stratégies de composition :

Request routing simple : Chaque route de la gateway correspond à un service spécifique.

/api/users/*     → User Service
/api/products/*  → Product Service
/api/orders/*    → Order Service

Agrégation des réponses : La gateway appelle plusieurs services et combine les réponses.

GET /api/dashboard
  → User Service : données de l'utilisateur
  → Order Service : dernières commandes
  → Product Service : recommandations
  ← Réponse combinée renvoyée au client

Avantages

• Découplage : Les clients ne connaissent pas la topologie interne des services
• Cross-cutting concerns centralisés : Auth, rate limiting et logging s’implémentent une seule fois
• Évolution indépendante : Vous pouvez réorganiser les services internes sans impacter les clients
• Simplification du client : Une seule URL, un seul format d’authentification
• Observabilité : Un point central pour les métriques, les logs et les traces de toutes les requêtes
• Sécurité : Les services internes ne sont pas exposés directement à internet

Compromis / Inconvénients

• Point unique de défaillance : Si la gateway tombe, tout le système devient inaccessible (nécessite une haute disponibilité)
• Latence supplémentaire : Chaque requête implique un saut réseau additionnel
• Complexité opérationnelle : La gateway nécessite son propre déploiement, sa supervision et son scaling
• Goulot d’étranglement : Tout le trafic passe par un seul composant (nécessite un scaling horizontal)
• Risque de logique métier : Il est tentant d’ajouter de la logique métier dans la gateway, ce qui constitue un anti-pattern
• Couplage à la gateway : Changer de technologie de gateway peut s’avérer coûteux

Quand l’utiliser

• Architectures de microservices avec plusieurs clients (web, mobile, IoT)
• Lorsque vous devez centraliser l’authentification et l’autorisation
• Lorsque les clients ont besoin de données agrégées provenant de plusieurs services
• Systèmes avec des exigences de rate limiting et de throttling
• Lorsque vous souhaitez masquer la complexité interne des services aux consommateurs externes

Quand l’éviter

• Applications monolithiques où il n’existe pas plusieurs services backend
• Systèmes internes où les services communiquent directement entre eux (service-to-service)
• Prototypes ou MVP où la complexité additionnelle ne se justifie pas
• Lorsque la latence additionnelle d’un saut supplémentaire est inacceptable

Technologies et implémentations courantes

Relation avec d’autres patterns

• BFF (Backend for Frontend) : Variante de l’API Gateway spécialisée par type de client
• Circuit Breaker : La gateway peut implémenter le circuit breaking vers les services downstream
• Rate Limiting : Fonctionnalité native de la gateway pour protéger les services
• Service Discovery : La gateway doit savoir où se trouvent les services (Consul, Eureka, DNS)

Prochaines étapes

L’API Gateway est le point d’entrée de votre architecture. Pour le spécialiser par type de client, explorez le pattern BFF (Backend for Frontend). Pour protéger les services downstream des défaillances en cascade, consultez le Circuit Breaker.