Api Layer
Nous pouvons ajouter une couche “API Layer” qui va faire office de reverse proxy ou de gateway entre nos services et l’interface utilisateur.
API Gateway
In a microservices architecture, an API gateway acts as a single entry point for client requests. The API gateway is responsible for request routing, composition, and protocol translation. It also provides additional features like authentication, authorization, caching, and rate limiting.
Pourquoi l’utiliser ?
L’avantage de cette pratique c’est qu’elle abstrait notre système derrière un “mur”. Les systèmes externes communiquent avec nos services uniquement au travers de la couche API. Cette couche peut par exemple s’assurer que l’utilisateur ait le droit de consulter la ressource (authentification et autorisation).
- L’utilisateur envoie une requête au service de Commande
- La couche API Layer contacte le service d’Authentification
- Le service d’authentification retourne une réponse autorisant ou non l’accès (e.g. vérifier si l’utilisateur saisi est le bon)
- Si l’authentification est réussite avec la couche API Layer transmet à requête au service Commande. Dans le cas contraire, l’API Layer ne contacte pas le service et retourne un code d’erreur au client (e.g. mot de passe incorrect)
On retrouve un fonctionnement similaire avec la librairie Spring Cloud Gateway
Rate Limiter
Il est parfois souhaité de limiter le nombre de de connexion d’un adresse IP, d’un utilisateur sur le serveur. Pour ce faire on utilise un Rate Limiter. Cet outil peut être mis en place sur le serveur ou sur une couche intermédiaire (middleware) entre le client et le serveur
Et si nous avons une architecture microservice possédant une API Gateway qui gère l’authentification, etc … nous pouvons y rajouter le Rate Limiter. Si une requête à atteint le nombre limite de demande alors une erreur 429 (too many request) est renvoyée.