GraphQL Federation, qu'est-ce que c'est ?

La fédération divise le schéma (le contrat entre les opérations back-end et front-end) en composants et microservices plus gérables, permettant aux équipes de développer, déployer et gérer des parties d'un schéma de manière indépendante, tout en conservant un graphe de données unifié pour les clients. 

Dans un environnement GraphQL fédéré, une passerelle GraphQL intègre plusieurs schémas, également appelés sous-graphiques ou services, dans un seul graphique (ou routeur). Chaque sous-graphe définit une partie du schéma global et gère la logique métier et la récupération des données pour ses propres types et champs. La passerelle relie ensuite les sous-graphes indépendants en un supergraphe, ce qui permet aux clients de consulter des sources de données à travers différents services comme s'ils interagissaient avec un seul schéma GraphQL.

Avant la fédération, l'une des principales méthodes pour combiner plusieurs schémas GraphQL était le « stitching de schéma », où différents schémas et résolveurs sont combinés manuellement. Les développeurs devaient définir la manière dont les schémas étaient fusionnés et comment les données étaient intégrées. La complexité et le caractère sujet aux erreurs du stitching de schéma en ont fait une solution difficile pour unifier les schémas GraphQL.

Apollo Federation, développé par les ingénieurs derrière Apollo, une implémentation GraphQL, est une solution conçue pour simplifier les processus de stitching de schéma. Apollo Federation utilise les mots-clés « key », « external », « requires » et « extends » pour établir des connexions entre les types répartis dans différents services. La passerelle Apollo, associée aux nouvelles fonctionnalités de référencement croisé, permet aux développeurs de construire un graphe de données cohérent sans avoir recours à une logique de stitching complexe.

Apollo GraphQL Federation était un concept innovant au-delà des simples outils et bibliothèques. Il s'agissait d'un système spécifié par son architecture et les règles de communication entre les services pour former un graphe distribué. En définissant une spécification système, Apollo GraphQL Federation a permis d'établir une norme pour la construction d'API GraphQL fédérées, favorisant ainsi l'adoption de ces principes par d'autres implémentations et outils.

GraphQL Federation a évolué considérablement depuis son introduction. La fédération gérée est une solution qui simplifie la collecte d'indicateurs et automatise les mises à jour de la passerelle en cas de modifications des sous-graphes, évitant ainsi les interventions manuelles et les temps d'arrêt.

Federation 2¹ est une innovation qui a apporté des améliorations significatives en simplifiant la fusion de schémas entre services, l'exécution de requêtes, en augmentant la modularité pour un meilleur contrôle de la composition de schémas et en améliorant la visibilité des erreurs pour un suivi et un débogage plus efficaces.

Apollo Federation reste une option pertinente pour les entreprises qui cherchent à déployer des architectures informatiques fédérées, en offrant une solution avancée pour la construction d'écosystèmes API rationalisés.

Cependant, une approche de fédération basée sur Apollo limite les développeurs à une implémentation spécifique à Apollo, car les environnements fédérés Apollo ne peuvent accepter que les directives et les types définis par Apollo, provenant d'Apollo ou de technologies back-end compatibles Apollo. En d'autres termes, Apollo Federation limite souvent la flexibilité du système, même avec l'émergence de nouvelles technologies.

Pour les développeurs qui souhaitent maximiser la flexibilité tout en bénéficiant des fonctionnalités de couche unifiée de la fédération Apollo, la fédération ouverte peut être une meilleure option. Les approches de fédération ouverte offrent une plus grande flexibilité en permettant aux systèmes de combiner des données provenant de n'importe quel fournisseur ou type d'API, y compris les API non-GraphQL. Grâce à des outils comme IBM API Connect, les entreprises peuvent personnaliser et faire évoluer leurs actifs informatiques sans être limitées par la compatibilité, tout en continuant à adopter les innovations de diverses communautés technologiques.

GraphQL aide les clients à demander exactement les données dont ils ont besoin sans sous-provisionner les ressources, ce qui en fait une excellente option pour les entreprises qui cherchent à optimiser leur efficacité opérationnelle.

Compte tenu de sa flexibilité, il n’est pas surprenant que GraphQL soit un langage de requête et un environnement d’exécution de plus en plus populaire pour les API.² Cependant, la complexité croissante des applications Web et mobiles rend le déploiement d'un serveur GraphQL monolithique unique (et de toutes ses dépendances) de plus en plus difficile. La fédération permet de simplifier les écosystèmes GraphQL en aidant des sous-graphes disparates à collaborer en tant que service GraphQL cohérent.

Les processus clés pour mettre en œuvre une architecture GraphQL fédérée sont les suivants.

La définition des schémas de sous-graphe consiste à identifier les limites de domaine et à déterminer comment ces limites doivent interagir. 

Dans une architecture fédérée, chaque schéma de sous-graphe représente une partie spécifique du graphe de données global ; il contient des types, des configurations, des requêtes, des mutations et des abonnements qui s'appliquent à un service ou un domaine. Un service de produit, par exemple, peut avoir un schéma de sous-graphe qui inclut des types tels que produit et avis, tandis qu’un service utilisateur peut avoir des types d’ utilisateur et de profil.

Les schémas de sous-graphe sont définis comme un schéma GraphQL standard, mais avec l'ajout de directives spécifiques à la fédération. Les directives de fédération donnent des instructions sur la manière d'étendre les entités entre les schémas et sur la façon dont la passerelle doit résoudre les champs spécifiques entre les services. Elles définissent également des clés pour référencer les entités.

Par exemple, la directive @key spécifie les champs qui identifient un type dans les graphes fédérés ; lorsqu'elle est déployée, cette directive incite la passerelle à récupérer une entité du service qui possède le type spécifié. La directive @extends indique qu'un type défini dans un schéma de sous-graphe étend un type qui provient d'un autre, facilitant l'extension de type (avec des champs supplémentaires) dans un autre service.

Les services de sous-graphe sont des services back-end qui implémentent la logique métier associée aux API de sous-graphe. Chaque service de sous-graphe est responsable de sa partie du graphe de données et traite les requêtes et les mutations liées à son domaine. Les résolveurs de chaque service de sous-graphe récupèrent les données associées à partir des sources de données appropriées, des bases de données ou des API REST.

La passerelle de fédération utilise les points de terminaison GraphQL révélés par les services de sous-graphe pour composer le schéma fédéré global. Il est important de noter que ces services peuvent être écrits dans n'importe quel langage de programmation, à condition qu'il prenne en charge GraphQL.

Les passerelles de fédération assurent l'orchestration de la composition de schéma et de la planification des requêtes. Les passerelles, avec l'aide des serveurs de fédération, présentent une API unifiée au client en masquant les services de sous-graphe individuels.

Pour configurer une passerelle de fédération, les équipes doivent spécifier l'emplacement de chaque service de sous-graphe et mettre en place l'infrastructure nécessaire pour la récupération de schéma, la planification de requête, l'exécution et le traitement des erreurs. La passerelle récupérera en permanence les schémas des services de sous-graphe pour s'assurer d'avoir le schéma fédéré le plus à jour.

Une fois les services de sous-graphe et la passerelle de fédération configurés, les administrateurs peuvent déployer l'ensemble du système. Le déploiement implique le provisionnement de matériel et de ressources cloud, la configuration de pipelines de déploiement, la surveillance des performances du système et la garantie d'une disponibilité élevée des ressources.

Évidemment, l'optimisation d'un environnement GraphQL fédéré nécessite une surveillance en temps réel cohérente. Une surveillance vigilante permet aux équipes de prévenir les problèmes plus importants en détectant et en résolvant rapidement les goulots d'étranglement de performance, les erreurs système et les temps d'arrêt non planifiés. La surveillance permet aussi de suivre la santé des services de sous-graphe et de la passerelle de fédération.

GraphQL Federation représente une avancée significative dans le développement d'API GraphQL pour les systèmes distribués à grande échelle. GraphQL Federation permet aux équipes de travailler indépendamment sur différentes parties d'un schéma GraphQL et d'intégrer leur travail de manière transparente dans une API unifiée, sans perturber l'expérience utilisateur final.

La fédération GraphQL offre une grande variété d’utilisations, allant du déploiement d’architecture microservice et du cache à l’analyse du développement de produits et des opérations. Il a été adopté par des entreprises telles que Netflix, Airbnb, GitHub et Expedia.

GraphQL Federation facilite également les démarches suivantes :