Patterns API Gateway : routage, sécurité et approche BFF
Un API gateway est la porte d'entrée de votre architecture microservices. Il gère les préoccupations transversales pour que les services individuels n'aient pas à le faire. Mais les décisions de conception du gateway ont des conséquences durables sur la performance, le couplage et l'autonomie des équipes.
Taxonomie des responsabilités
Responsabilités API Gateway
├── Gestion du trafic
│ ├── Routage des requêtes
│ ├── Répartition de charge
│ ├── Limitation de débit / throttling
│ ├── Circuit breaking
│ └── Routage canary / blue-green
├── Sécurité
│ ├── Authentification (validation JWT, OAuth2)
│ ├── Autorisation (vérification scope/rôle)
│ ├── Terminaison TLS
│ ├── Gestion CORS
│ └── Whitelist IP / intégration WAF
├── Transformation
│ ├── Mapping requête/réponse
│ ├── Traduction de protocole (REST↔gRPC)
│ ├── Injection d'en-têtes
│ └── Agrégation de réponses
└── Observabilité
├── Journalisation des accès
├── Tracing distribué (injection trace ID)
├── Collecte de métriques
└── Endpoints de health check
Comparaison des outils
| Fonctionnalité | Kong | Envoy | AWS API Gateway | Apigee (Google) | Traefik |
|---|---|---|---|---|---|
| Type | Gateway complet | Proxy / data plane | Service managé | Plateforme gérée | Routeur edge |
| Déploiement | Auto-hébergé ou cloud | Sidecar ou edge | Géré par AWS | Géré par GCP | Auto-hébergé ou cloud |
| Protocoles | HTTP, gRPC, WebSocket | HTTP/2, gRPC, TCP | HTTP, WebSocket | HTTP, gRPC | HTTP, TCP, gRPC |
| Plugins | Extensif (Lua, Go) | Filtres (C++, Wasm) | Autoriseurs Lambda | Policies (extensif) | Middlewares (Go) |
| Idéal pour | Gestion API à l'échelle | Proxy haute performance | Workloads AWS-natifs | Programme API entreprise | Ingress Kubernetes |
API Gateway vs Service Mesh
| Dimension | API Gateway | Service Mesh |
|---|---|---|
| Position | Edge (trafic nord-sud) | Interne (trafic est-ouest) |
| Rôle principal | Gestion API externe | Communication inter-services |
| Authentification | Identité externe (JWT, clé API) | mTLS entre services |
| Limitation de débit | Par client externe | Par service / par route |
| Observabilité | Métriques API, logs d'accès | Traces distribuées, métriques L7 |
| Déploiement | Centralisé (1 à quelques instances) | Distribué (sidecar par pod) |
| Outils | Kong, AWS APIGW, Apigee | Istio, Linkerd, Consul Connect |
Point clé : Ils sont complémentaires, pas concurrents. Utilisez un gateway pour le trafic externe et un mesh pour le trafic interne. Évitez de dupliquer les politiques entre les deux couches.
Anti-patterns
Le Gateway Dieu -- Mettre de la logique métier dans le gateway. Le gateway doit router et appliquer des politiques, pas contenir de logique domaine.
Gateway partagé entre équipes -- Quand le changement d'une équipe casse l'API d'une autre. Donnez aux équipes la propriété de leur configuration gateway.
Pas de gateway du tout -- Exposer les microservices directement signifie que chaque service réimplémente auth, rate limiting et CORS.