L’équipe du bureau CTO de F5 explore le domaine technologique lié aux API depuis plus d’un an maintenant. Ce dernier livre blanc s’inscrit dans la continuité de nos efforts pour comprendre l’écosystème des API en constante évolution.
Les défis que nous avons détaillés dans la gestion de la prolifération des API entraîneront des défis liés à la prolifération des passerelles API, et les approches traditionnelles pour relever ces défis ne seront pas suffisantes. Bien que les technologies graphiques telles que GraphQL soient très prometteuses pour maîtriser la complexité associée aux API, elles ne constituent qu’une partie de la solution, car les défis vont au-delà de la connectivité, de la sécurité et du routage. La bonne approche, basée sur près de trente ans d’expertise en matière de mise à l’échelle de systèmes et d’applications, repose sur une architecture distribuée, et non fédérée, qui utilise GraphQL mais ne s’appuie pas uniquement sur lui.
Cet article explore une approche architecturale distribuée pour relever les défis de la prolifération des passerelles API.
L’économie numérique sera alimentée par les API, ce qui nous donnera une économie pilotée par les API . Suite au livre blanc sur la prolifération des API , notre objectif était de comprendre comment éliminer ou atténuer l’impact de la prolifération des API. Bien que GraphQL semble prometteur pour réduire les ramifications de la prolifération des API, il tend à imposer aux développeurs la responsabilité de réécrire une grande partie de leur base de code API. Cependant, un point de vue émergent autour de GraphQL est sa capacité à être utilisé comme un acteur de passerelle efficace. L'acteur passerelle est une fonction ou un processus créé à proximité du client qui initie une demande d'API. Cet acteur de passerelle agit comme passerelle API initiale mettant fin à la demande d'API. Il peut également être éphémère, de sorte qu'il peut être détruit après avoir traité la demande.
Outre le fait que les développeurs et les équipes d'exploitation donnent la priorité à la gestion des API par rapport aux passerelles API, nous avons également découvert le problème de la prolifération des passerelles API en raison de la prolifération des API. Du point de vue du développeur, la principale préoccupation est de garantir que l'API fonctionne correctement et en temps opportun. D’autre part, l’équipe d’exploitation se concentre davantage sur des aspects tels que la découverte, la sécurité, la convivialité et les contrôles d’accès. Les passerelles API étant aujourd’hui un élément essentiel de l’infrastructure API, il est devenu évident que la prolifération des API augmente le déploiement des passerelles API, ce qui conduit à la prolifération des passerelles API.
L’avenir de l’architecture des API doit évoluer pour accepter la prolifération des API tout en simplifiant le déploiement et les opérations. L'architecture proposée constitue la prochaine évolution des modèles de conception de passerelle API. Bien que GraphQL ne soit pas au cœur de l’architecture, ni une nécessité, il a la capacité d’améliorer le modèle d’acteur de passerelle.
L’écosystème de gestion des API doit s’éloigner de la gestion des monolithes de passerelles API pour adopter une approche de conception de système plus contemporaine. Cela se traduira par un écosystème de gestion des API plus agile et plus efficace.
La prolifération des API, déjà un défi au sein de l'économie des API, entraîne également la prolifération des passerelles API , une situation dans laquelle la gestion des API est devenue incontrôlable en raison de la diversité des technologies des fournisseurs de passerelles API et des équipes opiniâtres qui gèrent les passerelles API. Nous nous trouvons à un point d’inflexion dans les architectures API, car la passerelle API héritée (API-GW) – une couche logicielle dédiée qui sert de point d’entrée pour les appels API – n’est plus suffisante pour gérer l’échelle et la complexité de l’écosystème API émergent.
La figure 1 illustre comment nous sommes passés de la gestion de la prolifération des API à la gestion de la prolifération des passerelles API.
Le modèle de conception ci-dessus fait allusion à un plan de contrôle centralisé, avec les passerelles API formant le plan de données distribué comme illustré dans la figure 2.
Les passerelles API sont un composant essentiel des architectures logicielles modernes, fournissant un point central de contrôle et de sécurité pour les API. Cependant, à mesure que le nombre de fonctionnalités offertes par les passerelles API a augmenté, elles sont devenues de plus en plus complexes et difficiles à gérer. Dans de nombreux cas, ces passerelles ont évolué vers des systèmes monolithiques, avec une large gamme de fonctionnalités regroupées dans un seul package.
Même si la gestion de plusieurs passerelles peut sembler être une conception distribuée, la réalité est qu’elle n’atteint pas une véritable distribution. Cela est dû au fait que les passerelles sont toujours étroitement couplées, partageant des ressources et des configurations difficiles à séparer. En conséquence, de nombreuses entreprises finissent par gérer des monolithes distribués et tous les défis que cela crée.
La figure 3 montre l’architecture des passerelles API existantes. Les requêtes API provenant du client sont d'abord transmises via un réseau partagé ou dédié, en passant par un pare-feu avant d'atteindre la passerelle API. La passerelle API, qui agit comme un proxy inverse, transmet ensuite le trafic à la charge de travail de l'API.
L'API-GW héritée devient un point d'étranglement de gestion des API lorsque les passerelles API sont déployées dans toute l'entreprise ou lorsque les charges de travail des API se déplacent de manière opérationnelle entre des régions, des zones, plusieurs clouds ou vers la périphérie tout en luttant contre la prolifération des API. Plusieurs API-GW sont créées par différentes équipes sans point unique de gestion et de contrôle d'entreprise. Si un individu ou un groupe de services API se déplace vers une infrastructure différente (cloud ou autre), l'équipe d'exploitation doit disposer d'une méthode pour migrer tous les aspects de la gestion des API : enregistrement, découverte, authentification, mise en réseau, sécurité et politiques de gouvernance, de risque et de conformité (GRC).
L’architecture représentée dans la Figure 3 n’est donc pas évolutive ni pratique à long terme, car au fil du temps, elle conduit à la gestion de monolithes distribués (Figure 2).
Il y a deux problèmes à l'origine du goulot d'étranglement de la passerelle API : (1) Prolifération des fournisseurs de passerelles API et (2) évolutivité au fur et à mesure lorsqu'une entreprise a plus d'applications exécutées dans plus d'endroits.
La figure 4 illustre un modèle d’acteurs de passerelle distribuée pour lutter contre la prolifération des passerelles API. Bien que le modèle distribué lui-même ne soit pas nouveau, cet article le formalise dans le contexte des passerelles API. Les clients initient la demande d’API. Les acteurs de passerelle distribués sont éphémères et instanciés à la demande au plus près du client. Il incombe à la couche de transport API d’envoyer la demande API de l’acteur de passerelle à la passerelle API simplifiée, qui achemine ensuite la demande vers la charge de travail API appropriée. Bien que l’utilisation du support GraphQL dans les acteurs distribués soit davantage un détail qu’une exigence pour que ce modèle fonctionne, il permet de prendre en charge des fonctionnalités telles que l’orchestration de services. Ainsi, au lieu de créer une nouvelle couche d’orchestration de services, GraphQL pourrait fournir ce support.
Pour clarifier, le sens de circulation est de droite à gauche. Autrement dit, les clients sont à droite et les requêtes API sont initiées par le client comme indiqué dans la Figure 5.
Il existe un modèle de déploiement émergent utilisant des acteurs de passerelle pour remplacer ou réduire la dépendance excessive aux passerelles API pour la gestion des API au sein et entre une entreprise. Bien que GraphQL ne soit pas nécessaire à l’architecture, son introduction est opportune car l’acteur passerelle est le bon véhicule pour prendre en charge GraphQL.
Pour acquérir une compréhension plus approfondie de l’acteur passerelle en tant que solution potentielle, il est nécessaire d’examiner de près l’état actuel des infrastructures API, en particulier des passerelles API. Cela est dû au fait que nous avons identifié l’étalement des passerelles comme un facteur important contribuant aux défis liés à l’exploitation et à la mise à l’échelle des infrastructures API.
Pour mieux comprendre les passerelles API, il est important d’examiner d’abord les différents composants de l’infrastructure de gestion des API moderne.
La figure 6 offre une représentation visuelle complète des différentes fonctionnalités et composants qui font partie intégrante de la gestion des API. Outre les passerelles API, nécessaires au routage et à la gestion du trafic vers les services back-end, il existe plusieurs autres composants d'infrastructure importants. Il peut s’agir notamment de solutions d’authentification, de limitation de débit, de mise en cache et de maillage de services. En intégrant ces fonctionnalités, les organisations peuvent contrôler leurs API, améliorer la sécurité et optimiser les performances.
Examinons les fonctionnalités communément reconnues et familières des passerelles API :
Après avoir analysé les fonctionnalités de l'infrastructure de gestion des API, nous avons identifié la nécessité de mieux comprendre le rôle des passerelles API et d'explorer des alternatives à la conception actuelle de la passerelle API monolithique.
Alors que la croissance du nombre d’API entraîne déjà une prolifération des API et des passerelles API, un nombre croissant de clients deviennent mobiles ou hautement distribués, et l’infrastructure de calcul est devenue disponible partout, y compris en périphérie. Nous avons donc besoin d’une approche capable d’améliorer l’agilité, la flexibilité, l’évolutivité, les performances et la sécurité de l’écosystème API.
Cette nouvelle approche nécessite une conception simplifiée capable d’exploiter pleinement les avantages d’une architecture véritablement distribuée.
Nous analysons plus en détail la fonctionnalité et la portée d'une passerelle API pour en faire ressortir les nuances et les limites.
Une passerelle API est un composant essentiel de l’infrastructure de gestion des API d’aujourd’hui. À la base, la passerelle API est un proxy inverse ; elle agit comme un intermédiaire entre les clients et les services back-end tout en effectuant diverses tâches sur la demande entrante. Par exemple, la passerelle peut authentifier, limiter le débit, demander un itinéraire, appliquer des politiques de sécurité, surveiller et appliquer le contrôle de version avant de transmettre la demande à un service back-end approprié. Une fois que le service backend a traité la demande et renvoyé une réponse, la passerelle API peut effectuer des tâches telles que la mise en cache, la traduction du protocole et la gestion des réponses avant de renvoyer la réponse au client.
À mesure que le nombre d’API a augmenté, les passerelles API ont évolué pour inclure une variété de nouvelles fonctionnalités au-delà du routage de base, devenant ainsi des systèmes monolithiques. Ces passerelles gèrent désormais des tâches telles que l’authentification et la limitation du débit pour améliorer les performances et réduire la charge sur les services back-end. Cependant, même avec ces fonctionnalités améliorées, les passerelles API restent un point d’accès unique au service backend, ce qui peut présenter des défis dans les environnements hautement distribués.
En particulier, l’essor du cloud, du multicloud hybride et des infrastructures de périphérie a rendu plus difficile le maintien de l’agilité, de la sécurité et de la facilité de gestion avec une approche de passerelle API. Les clients, les appareils et les charges de travail des applications étant potentiellement répartis sur un large éventail d’emplacements, une passerelle API peut ne pas être bien adaptée pour fournir le niveau nécessaire d’architecture conviviale.
Étant donné qu’elles gèrent un large éventail de tâches et doivent s’intégrer à plusieurs systèmes, les passerelles API sont généralement difficiles à déployer et à gérer. Bien que la gestion des passerelles API puisse être complexe, elle n'en demeure pas moins une tâche essentielle pour garantir la disponibilité, la sécurité et l'évolutivité d'une API. Les entreprises ont tendance à utiliser des outils spécialisés, tels que des plateformes de gestion d'API, pour gérer et surveiller plus efficacement leurs passerelles API.
La liste ci-dessous n'est pas exhaustive, mais certains des éléments contribuant à la complexité de la passerelle API incluent :
La prolifération des passerelles API fait référence à la prolifération de plusieurs passerelles API indépendantes au sein d'une organisation. Différentes équipes ou unités commerciales créent souvent leurs propres API, ce qui peut conduire à la création de plusieurs passerelles API indépendantes pour gérer ces différentes API. Différentes équipes peuvent également utiliser des passerelles API de différents fournisseurs ou solutions pour gérer différents types d’API.
Cela conduit au déploiement de plusieurs passerelles API, toutes dotées de différents ensembles de capacités.
La prolifération des passerelles API crée plusieurs défis supplémentaires :
Les entreprises doivent s’efforcer de centraliser leur gestion et leur gouvernance des API et d’utiliser un seul type de passerelle API. Même si cela permettra d’atténuer les défis susmentionnés liés à la prolifération des passerelles API, une stratégie homogénéisée pour les passerelles API est tout sauf simple.
À mesure que les entreprises se développent de manière organique ou par le biais d'acquisitions, les équipes internes alignées sur des unités commerciales (BU) spécifiques seront en désaccord les unes avec les autres lors de la sélection d'une technologie ou d'un fournisseur de passerelle API. Voici quelques raisons à cela :
Ainsi, si une application existante dispose d’une équipe bien établie et avisée, l’équipe ne voudra pas pivoter vers un modèle de déploiement différent afin de ne pas perturber son service.
Nous pouvons donc conclure qu’il est nécessaire d’adopter une nouvelle approche qui prenne en compte les multiples limitations de l’infrastructure API existante tout en soulignant la prolifération des passerelles API comme l’une des considérations les plus importantes.
La liste suivante n’est pas exhaustive, mais résume certaines des considérations de conception de haut niveau qui, selon nous, devraient être intégrées lors de la création de la solution :
Des exigences spécifiques peuvent être dérivées de ces considérations de conception, que nous avons intégrées dans notre solution d'acteurs de passerelle distribuée (DGA).
Après avoir maintenant pleinement exploré les passerelles API, nous pouvons expliquer la solution d’acteur de passerelle distribuée.
Le modèle de conception des acteurs de passerelle distribuée (DGA) s'inspire de l'informatique de pointe et de l'informatique disponible à proximité d'un client. L’essentiel de l’idée réside dans l’hyper-distribution de chaque acteur de passerelle aussi près que possible du client et dans le fait que l’acteur de passerelle n’existe que pendant la durée de la transaction avant qu’elle ne soit compensée à la fin.
Voici quelques-unes des hypothèses sous-jacentes à cette solution.
Le calcul en périphérie est devenu plus répandu et nous pouvons désormais trouver un type de calcul géographiquement disponible plus près du client. Les acteurs de la passerelle peuvent être instanciés sur ces nœuds de calcul de périphérie. L’objectif est d’avoir une implémentation où le DGA est très léger et éphémère afin qu’il puisse être instancié sur n’importe quel calcul de périphérie.
Le transport API est un élément crucial de l’infrastructure car il implique l’établissement d’un réseau entre les acteurs de la passerelle et la passerelle API. Le type d’infrastructure requis dépend du fournisseur ou de l’entreprise et peut varier. Par exemple, un grand cloud public peut utiliser sa propre dorsale pour exécuter le transport d’API. Une autre implémentation pourrait être un bus de messagerie à faible latence superposé sur un réseau existant à bande passante élevée et à faible latence au sein d’un centre de données d’entreprise.
Pour réitérer, la passerelle API est essentiellement un proxy inverse dont la fonction principale est d’acheminer le trafic HTTP vers les charges de travail API appropriées. Cette approche est logique lorsque toutes les API sont regroupées, comme au sein d’un réseau local sur site ou au sein d’un cloud privé virtuel (VPC) à l’intérieur d’une zone de disponibilité. Mais à mesure que le nombre d'API augmente, se déplace sur une infrastructure hybride ou devient simplement mobile, cette approche de conception de passerelle API devient inefficace, complexe à exploiter et coûteuse.
Bien qu’il puisse y avoir des points de vue différents sur la manière de classer toutes les fonctionnalités décrites dans la figure 6, nous pouvons convenir que l’infrastructure de gestion des API est devenue un déploiement complexe de nombreux composants qui doivent être soigneusement orchestrés.
La figure 7 illustre les différentes fonctionnalités et fonctions de la gestion des API de la figure 6 à l’architecture des acteurs de la passerelle distribuée. Cette cartographie illustre visuellement comment chaque fonctionnalité et fonction est alignée sur l'approche DGA, mettant en évidence l'intégration transparente des composants de gestion des API au sein de l'architecture.
La plupart des fonctionnalités répertoriées ci-dessus ont un composant de gestion qui peut être centralisé de manière logique. Notre objectif n’est pas de réarchitecturer le plan de gestion mais, si possible, de supprimer certaines fonctions.
Il s’agit de fonctions de plan de données et donc mieux implémentées dans l’API et colocalisées avec les charges de travail de l’application. Les passerelles API sont un composant essentiel de l’architecture de microservices moderne qui sert de point d’entrée pour tout le trafic externe. Nous avons catégorisé ses fonctions principales pour inclure le routage, l'équilibrage de charge, le routage dynamique, la vérification de l'état, les nouvelles tentatives et les replis.
Une passerelle API dirige les requêtes entrantes vers le microservice approprié, répartit le trafic sur plusieurs instances, prend en charge le routage dynamique, surveille l'état des microservices et de leurs instances, réessaye les requêtes ayant échoué et fournit des réponses de secours lorsqu'un microservice n'est pas disponible ou a échoué. D'autres fonctions telles que l'authentification, l'autorisation, la limitation du débit, la mise en cache et la journalisation peuvent être distribuées aux fonctions périphériques ou centralisées en fonction des exigences spécifiques du système.
Cette approche modulaire permet une architecture plus flexible et optimisée et est au cœur de notre recommandation pour simplifier, moderniser et faire évoluer l’infrastructure API de l’entreprise.
La passerelle API et la gestion des API sont souvent confondues à tort par les fournisseurs comme faisant partie de la fonction de passerelle API, mais il s'agit en fait de deux fonctions distinctes qui doivent être traitées séparément. Une passerelle API est chargée d'acheminer les demandes des clients vers les services back-end, tandis que la gestion des API englobe un ensemble plus large de fonctionnalités telles que le contrôle d'accès, la limitation du débit, l'analyse et la gestion du portail des développeurs.
Bien que certains fournisseurs puissent proposer à la fois des fonctions de passerelle API et de gestion des API dans le cadre d'un seul produit, il est important de comprendre les différences entre ces fonctions et de les évaluer séparément en fonction de leurs besoins spécifiques. La combinaison de ces fonctions peut entraîner une confusion et potentiellement limiter la flexibilité et l'évolutivité de l'infrastructure API d'une organisation. Ceci est également essentiel pour comprendre notre position sur la distribution de la fonctionnalité de passerelle API.
Les fonctionnalités répertoriées ici sont des fonctions principales qui doivent être intégrées au chemin de données. Dans un modèle de passerelle distribuée, certaines des fonctions en ligne de la passerelle API deviennent également distribuées. Ces fonctions incluent le contrôle d'accès, la limitation du débit, la validation des demandes, l'analyse des API, les rapports d'utilisation, la surveillance du taux d'erreur, les alertes et les événements, l'intégration de l'authentification, l'intégration de tiers, l'intégration de la surveillance et de la journalisation, la mise en cache de périphérie et la compression.
Le déplacement de ces fonctions vers le modèle de passerelle distribuée présente les avantages suivants :
Par exemple, le contrôle d’accès, la limitation du débit et la validation des demandes peuvent être gérés par un acteur de passerelle de périphérie, qui est déployé plus près des clients. Cela peut aider à réduire le nombre de requêtes devant être traitées par la passerelle API centralisée, améliorant ainsi ses performances et son évolutivité. De même, les analyses d’API, les rapports d’utilisation, la surveillance du taux d’erreur, les alertes et les événements, ainsi que l’intégration de la surveillance et de la journalisation peuvent être gérés par des passerelles périphériques, qui peuvent collecter et agréger des données à partir de plusieurs microservices.
Aujourd’hui, une capacité importante prise en charge par les passerelles API est la composition et l’orchestration des services. Bien que cela puisse devenir assez complexe, cela deviendrait un problème si cette fonctionnalité n’était pas prise en charge par la passerelle API simplifiée. Nous pensons que GraphQL peut être une approche intéressante pour la composition de services, agissant comme une sorte de middleware pour les API existantes.
En raison de sa visibilité sur toutes les API, la passerelle API devient un endroit logique pour effectuer la composition de services, permettant aux développeurs de combiner les API derrière la passerelle pour améliorer la logique métier sans avoir besoin d'écrire de nouveaux services qui peuvent être plus facilement combinés dans une couche de composition de services.
La composition de services dans GraphQL est rendue possible grâce à l'utilisation d'un schéma fortement typé, qui définit la forme des données disponibles pour les clients. Les clients peuvent utiliser ce schéma pour construire des requêtes qui spécifient les données exactes dont ils ont besoin, quels que soient les services ou les sources qui les fournissent. Les résolveurs, qui sont des fonctions qui mappent les requêtes aux sources de données, sont utilisés pour récupérer les données du service ou de la source appropriée. Cependant, même si GraphQL promet une meilleure sécurité, celle-ci n’est efficace que si le développeur qui écrit le code est bon.
Il reste encore quelques fonctionnalités non mises en évidence dans la figure 6 : Fonctionnalités de gestion et d'infrastructure des API . Ces fonctionnalités et fonctions restantes sont des candidats qui peuvent être déplacés vers des fonctions de gestion et d'exploitation individuelles ou vers des fonctions de plan de données.
Nous choisissons délibérément d’utiliser le terme « acteur » pour éviter de suggérer une implémentation ou une technologie de fournisseur spécifique. L’implémentation de l’acteur de passerelle peut être basée sur des méthodes, des fonctions, des travailleurs, des threads et des processus, implémentés à l’aide d’infrastructures basées sur des machines virtuelles, des conteneurs, sans serveur ou d’autres approches spécifiques à un fournisseur.
L’approche adoptée avec l’architecture des acteurs de passerelle distribuée (DGA) simplifie les fonctions de passerelle API et déplace d’autres fonctionnalités en ligne soit vers la périphérie, soit vers le plan de contrôle.
Outre les fonctionnalités de la passerelle API, l’architecture DGA recommande également d’identifier les fonctions qui pourraient être mieux servies dans le plan de contrôle en tant que composant logiquement centralisé plutôt qu’implémentées dans une passerelle API monolithique. La gestion et le contrôle de l’infrastructure API déjà existante peuvent être étendus et développés pour inclure cette fonctionnalité supplémentaire.
La simplification de la passerelle API devient ainsi un exercice visant à dériver un ensemble standard de fonctions de base que tous les fournisseurs de passerelles API peuvent gérer via un ensemble commun de paramètres de configuration.
Une entreprise souhaitant réaliser cette transformation pourrait déployer l’architecture DGA une application à la fois, sans perturber les déploiements existants et sans avoir recours à une opération de manutention.
Un aspect important du DGA est que chaque acteur de passerelle est éphémère, étant instancié uniquement pour la durée d'une session API (c'est-à-dire, un client effectuant un appel API).
Un acteur de passerelle distribué peut être plus flexible, évolutif et rentable que la passerelle API traditionnelle. Plutôt que de s'appuyer sur plusieurs passerelles API monolithiques de différents fournisseurs pour agréger et gérer le trafic API, l'acteur de passerelle permet aux développeurs de spécifier et de déployer des instances de passerelle individuelles pour chaque API plus proche de la périphérie du réseau. Les API elles-mêmes pourraient offrir un meilleur contrôle et une meilleure personnalisation pour répondre à leurs besoins spécifiques.
Cette nouvelle approche permet également une plus grande évolutivité, car les développeurs peuvent facilement faire tourner les instances d’acteur de passerelle selon les besoins pour gérer l’augmentation du trafic sans se soucier des frais généraux liés à la gestion d’une passerelle centralisée de grande taille.
Outre ses avantages techniques, l'acteur de passerelle offre également des économies de coûts par rapport à la passerelle API traditionnelle, en permettant aux entreprises de ne payer que pour les instances d'acteur de passerelle éphémères qu'elles utilisent. Ce modèle de déploiement peut ouvrir des opportunités pour des modèles de revenus supplémentaires.
En exploitant une couche de transport API, les DGA découplent essentiellement l’emplacement d’entrée de l’API de la passerelle API. Les DGA peuvent être déplacés vers la périphérie, c'est-à-dire plus près du client effectuant l'appel d'API. Les API peuvent se terminer dans les DGA et être ensuite transportées par n'importe quel moyen. Ceci est différent de la figure 3 : Architectures de passerelle API héritées où le trafic client entre topologiquement à côté des passerelles API.
Notre intention a donc été de proposer une approche indépendante du fournisseur et du déploiement, car différents fournisseurs peuvent avoir leur propre propriété intellectuelle pour créer ces composants afin d'atteindre des objectifs similaires à ceux décrits.
Dans cet article, nous avons résumé nos apprentissages issus de plusieurs études sur la prolifération des API , les architectures Edge 2.0 , l’ économie des API et les enquêtes sur GraphQL. Bien que le jury n’ait pas encore rendu son verdict concernant l’infrastructure API existante, nous pensons qu’une nouvelle approche est nécessaire.
La simple promesse de débloquer de la valeur au sein de chaque appareil ou entité individuelle à l’échelle mondiale constitue une raison suffisante pour explorer une nouvelle approche. Nous devons aujourd’hui nous éloigner de l’infrastructure API héritée, car même si elle semble distribuée, elle est monolithique sous le capot.
Nous proposons l'approche d'acteur de passerelle distribuée basée sur GraphQL comme un moyen indépendant du fournisseur pour libérer tout le potentiel de l'économie émergente des API.