API Gateway pour services Swift : comment unifier les microservices en un seul système

API Gateway pour services Swift : construire un pont entre les microservices

Imaginez que votre backend est un immense centre commercial. À l'intérieur, des dizaines de magasins (microservices) : authentification, catalogue de produits, panier, paiements, notifications. Le client (application iOS) doit entrer dans chaque magasin séparément — c'est le chaos, long et peu sécurisé. API Gateway est l'entrée principale, la sécurité et le guide tout-en-un. Il reçoit les requêtes, vérifie les laissez-passer, redirige vers le bon service et renvoie le résultat.

Dans le monde Swift, où Vapor et Hummingbird gagnent en popularité, créer sa propre API Gateway n'est pas un luxe, mais une nécessité pour les projets évolutifs. Aujourd'hui, nous allons voir comment écrire une gateway légère en Swift qui unifiera vos services en un seul écosystème.

Pourquoi une API Gateway dans une architecture Swift ?

Lorsque vous avez 2-3 microservices, le client peut communiquer directement avec chacun. Mais quand ils sont 10+ (scénario typique pour la fintech, l'e-commerce ou le SaaS), des problèmes apparaissent :

\n
• Code client gonflé — chaque service a son propre endpoint, format d'erreur, protocole d'authentification
\n
• Vulnérabilités — chaque service doit gérer lui-même le CORS, le rate limiting, la vérification JWT
\n
• Complexité du refactoring — vous avez renommé un service ? Modifiez le code sur tous les clients
\n
• Trafic superflu — le client fait 5 requêtes au lieu d'une pour charger une page
\n

L'API Gateway résout ces problèmes en devenant un point d'entrée unique. Il peut agréger les données de plusieurs microservices en une seule réponse, appliquer des politiques de sécurité et journaliser toutes les requêtes. Pour les développeurs Swift, c'est aussi l'occasion d'utiliser le typage strict du langage au niveau de la passerelle.

Choix de l'outil : Vapor + Hummingbird

Pour créer une API Gateway en Swift, Vapor est idéal — le framework web le plus mature de l'écosystème. Il propose des middleware, du routage, des requêtes client (via Client) et le support d'async/await. L'alternative est Hummingbird (léger, rapide, d'Apple), mais pour l'exemple, nous utiliserons Vapor, mieux documenté.

Notre gateway remplira trois fonctions :

\n
• Proxy des requêtes vers le microservice approprié
\n
• Authentification via JWT
\n
• Agrégation des données de deux services en une seule réponse
\n

Étape 1. Structure de base du projet

Créons un nouveau projet Vapor :

vapor new APIGateway --template=api\ncd APIGateway

Ajoutons dans Package.swift la dépendance pour JWT :

.package(url: "https://github.com/vapor/jwt.git", from: "4.0.0")

Et connectons-la dans la cible :

.target(name: "App", dependencies: [\n    .product(name: "Vapor", package: "vapor"),\n    .product(name: "JWT", package: "jwt")\n])

Étape 2. Middleware pour l'authentification

Créons un middleware qui vérifie le token JWT et transmet les informations utilisateur. C'est un modèle classique pour une API Gateway en Swift :

import Vapor\nimport JWT\n\nstruct JWTAuthenticator: AsyncMiddleware {\n    func respond(to request: Request, chainingTo next: AsyncResponder) async throws -> Response {\n        guard let token = request.headers.bearerAuthorization?.token else {\n            throw Abort(.unauthorized, reason: "Missing Bearer token")\n        }\n        \n        // Vérifie la signature et la date d'expiration\n        let payload = try await request.jwt.verify(token, as: UserPayload.self)\n        \n        // Sauvegarde l'utilisateur dans le stockage de la requête\n        request.storage.set(UserPayloadKey.self, to: payload)\n        \n        return try await next.respond(to: request)\n    }\n}\n\nstruct UserPayload: JWTPayload {\n    var userID: UUID\n    var role: String\n    var exp: ExpirationClaim\n    \n    func verify(using signer: JWTSigner) throws {\n