Maîtriser le gateway : protocoles, proxies et le maillage moderne
SchemaBridge Team · 2026-01-14 · Protocols, REST, API
Un gateway HTTP configurable pour un cloud fragmenté : retries bornés, limites de débit par destination et secrets injectés en sortie.
La soupe de protocoles : vivre à l'ère de la fragmentation infinie
À en croire le battage médiatique, le monde est entièrement RESTful sur HTTPS avec du JSON. À en croire le vrai battage médiatique, le monde migre vers GraphQL ou gRPC. Mais si l'on regarde la réalité d'un paysage informatique d'entreprise moderne, le monde est une soupe de protocoles désordonnée et non coordonnée, qui couvre quatre décennies de modes architecturales.
Dans une seule organisation, vous avez probablement :
- Le moderne : une flotte d'applications React qui dialoguent avec des endpoints GraphQL.
- Le cheval de trait : des milliers de microservices internes exposant des API REST.
- Les tiers : divers fournisseurs SaaS avec des limites de débit et des exigences d'en-têtes spécifiques.
L'intégration est l'art de construire un pont au-dessus de cette soupe de protocoles. Traditionnellement, cela signifiait écrire des « services adaptateurs » — de petits programmes Node ou Go fragiles qui ne faisaient rien d'autre qu'un appel HTTP. Nous appelions cela du « code glue » (voir La crise du code glue), et c'est un fardeau énorme pour la vélocité de l'ingénierie.
Chez SchemaBridge, nous nous y attaquons avec le Managed Gateway : un gateway HTTP configurable pour les API de style REST, qui découple votre logique métier de l'implémentation spécifique de l'endpoint. Il s'agit délibérément d'un seul protocole, bien maîtrisé (HTTP avec GET, POST, PUT et DELETE) ; il n'y a pas de client GraphQL, gRPC ou SOAP intégré, donc ces endpoints sont atteints via leur surface HTTP, ou pas du tout.
L'architecture du Managed Gateway
Un gateway SchemaBridge est plus qu'un proxy. C'est un intermédiaire qui prend en charge la « maintenance des connexions » de votre infrastructure : retries, limites de débit et identifiants.
Normalisation des réponses : l'approche JSONata d'abord
Au lieu d'écrire du code pour parser les réponses, vous associez le gateway à une étape TRANSFORMATION.
1. Appel : le vertex GATEWAY appelle le service externe et restitue le résultat sous forme de response.statusCode et response.body. Un corps JSON arrive déjà parsé ; tout le reste arrive sous forme de chaîne brute.
2. Mapping : une transformation JSONata en aval extrait et remodèle les champs précis dont votre workflow a besoin.
Appliqué de façon systématique, cela signifie que le reste de votre logique visuelle ne voit jamais que la forme propre que vous avez définie, quelle que soit la structure de la source sous-jacente.
Politiques de retry adaptatives : au-delà de la limite des 3 tentatives
La plupart des développeurs utilisent une politique de « retry fixe » : 3 tentatives avec un délai d'une seconde. Cela fait souvent plus de mal que de bien. Si un service est tombé à cause de la charge, une flotte de workers qui retente chaque seconde agit comme une attaque DDoS coordonnée et empêche le service de se rétablir.
Les gateways SchemaBridge retentent avec backoff, et dans certaines limites :
- Backoff exponentiel : un 5xx, un 429 ou une erreur réseau est retenté jusqu'à 3 fois, en doublant l'attente à chaque fois (1 s, 2 s, 4 s). Les autres réponses 4xx ne sont pas retentées, car répéter une requête invalide ne la corrige pas.
- Retry-After respecté : sur un 429, le gateway respecte l'en-tête
Retry-Afterdu fournisseur (plafonné à 30 secondes) au lieu de deviner. - Admission adaptative : pour les destinations surchargées, le limiteur de débit par destination de la plateforme adapte son débit à ce que le fournisseur accepte réellement, en ralentissant en cas de throttling et en remontant en cas de succès, afin de ne pas marteler une API en difficulté.
Un fournisseur toujours surchargé après les retries HTTP voit l'étape redispatchée quelques fois de plus via le contrôle d'admission (maxAutoRetries, 3 par défaut). S'il échoue toujours après cela, l'étape échoue de manière visible et peut être relancée une fois le fournisseur rétabli, au lieu de boucler indéfiniment.
Gérer la guerre des limites de débit : contrôle global de la concurrence
Chaque fournisseur SaaS a une limite de débit. Certaines sont simples (10 requêtes par seconde). Si 100 workers exécutent votre intégration, comment se coordonnent-ils pour rester sous la limite ?
Si chaque worker essaie de suivre son propre débit, vous la dépasserez inévitablement et serez bloqué. SchemaBridge fournit des limites par destination à l'échelle du workspace, appliquées au moment du dispatch :
- Débit : un token bucket par workspace et par destination plafonne le nombre de requêtes par seconde sur l'ensemble des workers.
- Concurrence : un plafond de concurrence par destination (configurable sur la page Rate Limits) limite le nombre d'appels vers cette API pouvant être en cours simultanément. Chaque vertex qui appelle cette API doit le franchir avant de s'exécuter.
Comparatif : API gateway traditionnel vs gateway SchemaBridge
| Caractéristique | API Gateway (Apigee/Kong) | SchemaBridge Managed Gateway |
| :--- | :--- | :--- |
| Cible | Trafic entrant (nord-sud) | Appels métier sortants (egress) |
| État | Surtout à l'échelle de la requête (compteurs, caches) | Retries bornés au-dessus d'une exécution persistée |
| Logique | Scripting (Lua/JS) | Visuelle (JSONata) |
| Identité | Vérification de l'authentification | Secrets injectés en sortie ({{ secrets.NAME }}) |
Normalisation des payloads : la mort du service adaptateur
Comme nous l'avons vu plus tôt dans cette série, écrire des services spécialisés pour convertir des données est un gaspillage de talents d'ingénieurs seniors. Associer le gateway à une transformation partagée fait de la normalisation une propriété du lien.
Deux primitives rendent cette réutilisation concrète. Une custom app capture une seule fois la configuration de connexion d'un fournisseur (URL de base, en-têtes, authentification) pour votre workspace et la pré-remplit dans chaque gateway qui l'utilise. Une règle de transformation persistée capture le mapping une seule fois, sous un ruleId, de sorte que tous les workflows qui dialoguent avec le même ERP legacy la partagent. Vous avez déplacé la « charge technique » dans la plateforme et gardé la « logique métier » propre et visuelle.
Scénario illustratif : porter une API legacy vers le web moderne
Prenons un groupe de distribution multinational qui modernise son système de gestion des commandes.
Le défi
Imaginez que son inventaire central réside dans un système legacy instable couvrant des milliers de magasins, tandis que son nouveau frontend e-commerce est une application React/Next.js. Relier ces deux mondes avec un ensemble de « microservices adaptateurs » écrits à la main serait un chantier majeur, sur plusieurs trimestres.
La méthode SchemaBridge
Imaginez plutôt l'équipe s'appuyant sur la primitive gateway de SchemaBridge.
1. Configuration du gateway : au lieu d'écrire du code, ils configurent le système legacy comme une custom app dans SchemaBridge, avec ses identifiants conservés dans le coffre de secrets chiffré.
2. Logique visuelle : leur équipe produit construit directement le graphe visuel « Check Inventory ».
3. Résilience intégrée : les retries avec backoff du gateway absorbent les pannes courtes et transitoires du système legacy, et les limites par destination empêchent le trafic du frontend de le submerger.
Le résultat plausible
- Calendrier : une grande partie de ce qui ressemblait à un projet d'adaptateurs sur plusieurs trimestres pourrait devenir du travail de configuration.
- Charge : comme la concurrence vers le système legacy est plafonnée de manière centralisée, un pic de trafic sur le frontend serait mis en file d'attente au niveau de la plateforme plutôt que de faire tomber le système legacy.
L'avenir : l'entreprise agnostique au protocole
Le protocole spécifique d'une API devrait être un détail d'implémentation, pas un frein sur la feuille de route. En évoluant vers un modèle de maîtrise du gateway, nous nous libérons du « fantôme du legacy ». Nous bâtissons notre logique métier sur un socle de vérité propre et hiérarchique, tandis que notre infrastructure gère la réalité désordonnée du cloud fragmenté.
Checklist d'expert pour la conception d'un gateway
Lorsque vous concevez votre couche d'intégration, suivez ces heuristiques pour vos connexions sortantes :
1. Isolez le protocole : votre logique métier ne devrait jamais contenir de détails d'implémentation propres à un protocole. Abstrayez-les dans le gateway et son étape de transformation.
2. Mettez vos identifiants au coffre : ne collez jamais d'en-têtes d'authentification dans la configuration. Référencez-les sous la forme {{ secrets.NAME }} afin que le jeton ne soit injecté qu'au moment où la requête quitte la plateforme.
3. Faites du backoff, et plafonnez-le : ne vous contentez pas de « réessayer dans 1 s ». Utilisez un backoff exponentiel, respectez Retry-After et plafonnez la concurrence par destination. Si vous contrôlez les clients, ajoutez aussi du jitter pour étaler les retries synchronisés.
Conclusion : le pont, c'est le gateway
L'infrastructure est l'art de gérer les détails désordonnés pour que la logique puisse rester pure. La maîtrise du gateway est l'étape finale pour découpler votre vélocité d'ingénierie de la dette technique du passé. Arrêtez d'écrire des adaptateurs et commencez à construire des ponts.
À lire aussi, dans notre série « Building the Bridge » : Reprise sur erreur, sur la gestion des échecs comme un cycle de vie métier à part entière.