Gateway API Frontend : Fédération GraphQL et Schema Stitching

Dans le monde du développement d'applications web modernes, la gestion des données provenant de sources multiples peut représenter un défi de taille. À mesure que les applications gagnent en complexité et adoptent des architectures de microservices, le besoin d'un moyen unifié et efficace pour accéder aux données devient primordial. Une Gateway API Frontend agit comme un point d'entrée central pour les applications clientes, agrégeant les données de divers services backend et offrant une expérience simplifiée tant pour les développeurs que pour les utilisateurs finaux. Cet article de blog explore deux techniques puissantes pour construire une Gateway API Frontend : la Fédération GraphQL et le Schema Stitching.

Qu'est-ce qu'une Gateway API Frontend ?

Une Gateway API Frontend est un modèle architectural où un serveur dédié agit comme intermédiaire entre les clients frontend (par exemple, les navigateurs web, les applications mobiles) et de multiples services backend. Elle simplifie la récupération de données en :

• Agrégation de données : Combiner les données de plusieurs sources en une seule réponse.
• Transformation de données : Adapter les formats de données pour répondre aux besoins du frontend.
• Abstraction de la complexité : Masquer les subtilités des services backend au client.
• Application de la sécurité : Mettre en œuvre des politiques d'authentification et d'autorisation.
• Optimisation des performances : Mettre en cache les données fréquemment consultées et réduire les requêtes réseau.

Essentiellement, elle met en œuvre le modèle Backend for Frontend (BFF) à grande échelle et permet aux équipes front-end de prendre davantage le contrôle des API qu'elles consomment. Dans les grandes organisations, le fait que le front-end gère et organise ses propres API peut conduire à une livraison plus rapide et à une dépendance réduite vis-à-vis des équipes backend.

Pourquoi utiliser GraphQL pour une Gateway API Frontend ?

GraphQL est un langage de requête pour les API et un environnement d'exécution pour répondre à ces requêtes avec vos données existantes. Il offre plusieurs avantages par rapport aux API REST traditionnelles, ce qui le rend bien adapté à la construction de Gateways API Frontend :

• Récupération de données efficace : Les clients ne demandent que les données dont ils ont besoin, ce qui réduit la sur-récupération (over-fetching) et améliore les performances.
• Typage fort : Les schémas GraphQL définissent la structure des données, ce qui permet un meilleur outillage et une meilleure validation.
• Introspection : Les clients peuvent découvrir les données et les opérations disponibles grâce à l'introspection du schéma.
• Capacités en temps réel : Les abonnements GraphQL permettent des mises à jour de données en temps réel.

En tirant parti de GraphQL, une Gateway API Frontend peut fournir une interface flexible, efficace et conviviale pour les développeurs pour accéder aux données de plusieurs services backend. Cela contraste fortement avec les approches traditionnelles utilisant de multiples points de terminaison REST, chacun devant être interrogé individuellement et renvoyant souvent plus de données que nécessaire.

Fédération GraphQL : Une Approche Distribuée

Qu'est-ce que la Fédération GraphQL ?

La Fédération GraphQL est une technique puissante pour construire une API GraphQL distribuée en composant plusieurs services GraphQL (appelés "sous-graphes") en un schéma unique et unifié. Chaque sous-graphe est responsable d'un domaine ou d'une source de données spécifique, et la passerelle de fédération orchestre les requêtes à travers ces sous-graphes.

Le concept de base tourne autour d'un supergraphe, un schéma GraphQL unique et unifié qui représente l'ensemble de l'API. Ce supergraphe est construit en composant des schémas GraphQL plus petits, appelés sous-graphes, chacun représentant un microservice ou une source de données spécifique. La passerelle de fédération est chargée d'acheminer les requêtes GraphQL entrantes vers les sous-graphes appropriés et de combiner les résultats en une seule réponse.

Comment fonctionne la Fédération GraphQL

1. Définition des sous-graphes : Chaque microservice expose une API GraphQL (un sous-graphe) qui définit ses propres données et opérations. Ces schémas incluent des directives qui indiquent à la passerelle de fédération comment résoudre les types et les champs. Les directives clés incluent `@key`, `@external` et `@requires`.
2. Composition du supergraphe : La passerelle de fédération (par exemple, Apollo Gateway) récupère les schémas de chaque sous-graphe et les compose en un schéma unique et unifié (le supergraphe). Ce processus implique la résolution des conflits de types et de champs et l'établissement de relations entre les types à travers différents sous-graphes.
3. Planification et exécution des requêtes : Lorsqu'un client envoie une requête GraphQL à la passerelle, celle-ci analyse la requête et détermine quels sous-graphes doivent être interrogés pour satisfaire la demande. Elle distribue ensuite la requête aux sous-graphes appropriés, collecte les résultats et les combine en une seule réponse, qui est renvoyée au client.

Exemple : Plateforme de e-commerce avec la Fédération GraphQL

Considérez une plateforme de e-commerce avec des microservices distincts pour les produits, les clients et les commandes.

• Sous-graphe Produits : Gère les informations sur les produits (nom, description, prix, etc.).
• Sous-graphe Clients : Gère les données des clients (nom, adresse, email, etc.).
• Sous-graphe Commandes : Gère les informations sur les commandes (ID de commande, ID client, ID de produits, montant total, etc.).

Chaque sous-graphe expose une API GraphQL, et la passerelle de fédération compose ces API en un seul supergraphe. Un client peut alors interroger le supergraphe pour récupérer des informations sur les produits, les clients et les commandes en une seule requête.

Par exemple, une requête pour récupérer le nom d'un client et son historique de commandes pourrait ressembler à ceci :

query GetCustomerAndOrders($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    orders {
      id
      orderDate
      totalAmount
    }
  }
}

La passerelle de fédération acheminerait cette requête vers les sous-graphes Clients et Commandes, récupérerait les données nécessaires et les combinerait en une seule réponse.

Avantages de la Fédération GraphQL

• Accès aux données simplifié : Les clients interagissent avec un seul point de terminaison GraphQL, quelles que soient les sources de données sous-jacentes.
• Performances améliorées : La récupération des données est optimisée en ne récupérant que les données nécessaires de chaque sous-graphe.
• Scalabilité accrue : Chaque sous-graphe peut être mis à l'échelle indépendamment, permettant une meilleure utilisation des ressources.
• Développement décentralisé : Les équipes peuvent développer et déployer des sous-graphes indépendamment, favorisant l'agilité et l'innovation.
• Gouvernance du schéma : La passerelle de fédération assure la cohérence et la compatibilité du schéma entre les sous-graphes.

Outils pour la Fédération GraphQL

• Apollo Federation : Une implémentation open-source populaire de la Fédération GraphQL, fournissant une passerelle, un registre de schémas et des outils pour construire et gérer des API GraphQL fédérées. Apollo Federation est réputée pour sa scalabilité et sa gestion robuste des erreurs.
• GraphQL Hive : Cet outil offre un registre de schémas et une gouvernance pour les services fédérés GraphQL, fournissant des fonctionnalités comme la détection des changements, l'analyse de l'utilisation et les vérifications de schémas. Il améliore la visibilité et le contrôle sur le supergraphe.

Schema Stitching : Une Approche Alternative

Qu'est-ce que le Schema Stitching ?

Le Schema Stitching est une autre technique pour combiner plusieurs schémas GraphQL en un schéma unique et unifié. Contrairement à la Fédération, le Schema Stitching implique généralement un processus plus manuel de définition de la manière dont les types et les champs de différents schémas sont connectés. Bien que la Fédération soit considérée comme une solution plus moderne et robuste, le Schema Stitching peut être une option viable pour des cas d'utilisation plus simples ou lors de la migration d'API GraphQL existantes.

Comment fonctionne le Schema Stitching

1. Définition du schéma : Chaque microservice expose une API GraphQL avec son propre schéma.
2. Logique de couture (stitching) : Une couche de stitching (souvent implémentée à l'aide de bibliothèques comme GraphQL Tools) définit comment les types et les champs de différents schémas sont connectés. Cela implique d'écrire des fonctions de résolution (resolvers) qui récupèrent les données des services sous-jacents et les mappent sur le schéma unifié.
3. Schéma unifié : La couche de stitching combine les schémas individuels en un seul schéma unifié qui est exposé au client.

Exemple : Stitching de Produits et d'Avis

Imaginez deux services GraphQL distincts : un pour les produits et un autre pour les avis.

• Service Produits : Fournit des informations sur les produits (ID, nom, description, prix).
• Service Avis : Fournit des avis sur les produits (ID, ID de produit, note, commentaire).

En utilisant le Schema Stitching, vous pouvez créer un schéma unifié qui permet aux clients de récupérer les informations sur les produits et les avis en une seule requête.

Vous définiriez une fonction de résolution dans la couche de stitching qui récupère les avis pour un ID de produit donné à partir du Service Avis et les ajoute au type Produit dans le schéma unifié.

// Exemple (Conceptuel) : logique de stitching avec GraphQL Tools
const { stitchSchemas } = require('@graphql-tools/stitch');

const productsSchema = ... // Définissez votre schéma de produits
const reviewsSchema = ... // Définissez votre schéma d'avis

const stitchedSchema = stitchSchemas({
  subschemas: [
    {
      schema: productsSchema,
    },
    {
      schema: reviewsSchema,
      transforms: [
        {
          transformSchema: (schema) => schema,
          transformRequest: (originalRequest) => {
            return originalRequest;
          },
          transformResult: (originalResult) => {
            return originalResult;
          }
        }
      ],
    },
  ],
  typeDefs: `
    extend type Product {
      reviews: [Review]
    }
  `,
  resolvers: {
    Product: {
      reviews: {
        resolve: (product, args, context, info) => {
          // Récupérer les avis pour le produit depuis le Service Avis
          return fetchReviewsForProduct(product.id);
        },
      },
    },
  },
});

Cet exemple illustre le concept de base de la couture de schémas. Notez la nécessité de résolveurs personnalisés pour récupérer le champ `reviews`. Cette surcharge de codage des résolveurs pour chaque relation peut rendre le processus de développement plus lent que l'utilisation de la Fédération.

Avantages du Schema Stitching

• API unifiée : Les clients accèdent à un seul point de terminaison GraphQL, ce qui simplifie l'accès aux données.
• Adoption incrémentale : Le Schema Stitching peut être mis en œuvre de manière incrémentale, vous permettant de migrer progressivement vers une API unifiée.
• Flexibilité : Le Schema Stitching offre plus de contrôle sur la manière dont les schémas sont combinés, vous permettant de personnaliser la logique de couture pour répondre à des besoins spécifiques.

Inconvénients du Schema Stitching

• Configuration manuelle : Le Schema Stitching nécessite une configuration manuelle de la logique de couture, ce qui peut être complexe et prendre du temps.
• Surcharge de performance : Les fonctions de résolution peuvent introduire une surcharge de performance, surtout si elles impliquent des transformations de données complexes.
• Scalabilité limitée : Le Schema Stitching peut être plus difficile à mettre à l'échelle que la Fédération, car la logique de couture est généralement centralisée.
• Propriété du schéma : Peut entraîner une ambiguïté sur la propriété du schéma, en particulier si différentes équipes gèrent les services assemblés.

Outils pour le Schema Stitching

• GraphQL Tools : Une bibliothèque populaire pour construire et manipuler des schémas GraphQL, incluant le support pour le Schema Stitching.
• GraphQL Mesh : GraphQL Mesh vous permet d'utiliser le langage de requête GraphQL pour accéder aux données de diverses sources comme les API REST, les bases de données et gRPC. Il peut assembler ces API en un schéma GraphQL unifié.

Fédération GraphQL vs. Schema Stitching : Une Comparaison

La Fédération GraphQL et le Schema Stitching offrent tous deux des moyens de combiner plusieurs schémas GraphQL en une seule API, mais ils diffèrent dans leur approche et leurs capacités.

Fonctionnalité	Fédération GraphQL	Schema Stitching
Approche	Composition distribuée et automatisée	Configuration centralisée et manuelle
Complexité	Complexité moindre pour la maintenance et la mise à l'échelle	Complexité plus élevée en raison de la logique de résolution manuelle
Scalabilité	Conçue pour les systèmes distribués à grande échelle	Moins scalable, généralement utilisée pour des applications plus petites
Gouvernance du schéma	Gouvernance et validation de schéma intégrées	Nécessite une gestion et une coordination manuelles du schéma
Outillage	Écosystème robuste d'outils et de bibliothèques (par ex., Apollo Federation)	Nécessite plus d'outillage et de configuration personnalisés
Cas d'utilisation	Architectures de microservices, API à grande échelle, développement décentralisé	Applications plus petites, migration incrémentale, exigences de personnalisation spécifiques

Quand utiliser la Fédération GraphQL : Choisissez la Fédération lorsque vous avez une architecture de microservices complexe, que vous avez besoin de mettre à l'échelle votre API et que vous voulez permettre à des équipes indépendantes de gérer leurs propres sous-graphes. Elle simplifie également la gestion et la gouvernance du schéma.

Quand utiliser le Schema Stitching : Envisagez le Schema Stitching lorsque vous avez une API plus simple, que vous avez besoin de plus de contrôle sur la logique de couture, ou que vous migrez depuis des API GraphQL existantes. Cependant, soyez conscient des complexités potentielles et des limitations de scalabilité.

Implémentation de l'Authentification et de l'Autorisation

Que vous choisissiez la Fédération GraphQL ou le Schema Stitching, l'implémentation de l'authentification et de l'autorisation est cruciale pour sécuriser votre Gateway API Frontend. Il existe plusieurs approches que vous pouvez adopter :

• Authentification au niveau de la passerelle : La Gateway API gère l'authentification et l'autorisation avant de router les requêtes vers les services backend. Cette approche centralise la logique de sécurité et simplifie les services backend. Les méthodes courantes incluent la validation de JWT (JSON Web Token) et OAuth 2.0.
• Authentification au niveau du service : Chaque service backend gère sa propre authentification et autorisation. Cette approche offre un contrôle plus granulaire sur la sécurité mais peut être plus complexe à gérer.
• Approche hybride : Une combinaison de l'authentification au niveau de la passerelle et du service. La passerelle gère l'authentification initiale, et les services backend effectuent des vérifications d'autorisation plus granulaires.

Exemple : Authentification JWT avec Apollo Federation

Avec Apollo Federation, vous pouvez configurer la passerelle pour valider les jetons JWT inclus dans les en-têtes de la requête. La passerelle peut ensuite transmettre les informations de l'utilisateur extraites du jeton aux sous-graphes, qui peuvent utiliser ces informations pour l'autorisation.

// Exemple (Conceptuel) : configuration d'Apollo Gateway avec validation JWT
const { ApolloGateway } = require('@apollo/gateway');

const gateway = new ApolloGateway({
  serviceList: [
    // ... vos configurations de sous-graphes
  ],
  buildService: ({ name, url }) => {
    return new MyCustomService({
      name,  // Nom du sous-graphe
      url,   // URL du sous-graphe
    });
  },
});

class MyCustomService extends RemoteGraphQLDataSource {
  willSendRequest({ request, context }) {
    // Obtenir l'utilisateur depuis le contexte
    const user = context.user;

    // Ajouter l'ID de l'utilisateur aux en-têtes de la requête
    if (user) {
      request.http.headers.set('user-id', user.id);
    }
  }
}

Dans cet exemple, un service personnalisé est créé pour modifier les requêtes sortantes afin d'inclure l'ID de l'utilisateur dérivé du JWT. Les services en aval peuvent ensuite utiliser cet ID pour les vérifications d'autorisation.

Stratégies de Mise en Cache pour l'Optimisation des Performances

La mise en cache est essentielle pour améliorer les performances d'une Gateway API Frontend. En mettant en cache les données fréquemment consultées, vous pouvez réduire la charge sur les services backend et améliorer les temps de réponse pour les clients. Voici quelques stratégies de mise en cache :

• Mise en cache HTTP : Tirez parti des mécanismes de mise en cache HTTP (par ex., les en-têtes `Cache-Control`) pour mettre en cache les réponses dans le navigateur et les proxys intermédiaires.
• Mise en cache en mémoire : Utilisez des caches en mémoire (par ex., Redis, Memcached) pour mettre en cache les données fréquemment consultées sur la passerelle.
• Mise en cache CDN : Utilisez les réseaux de diffusion de contenu (CDN) pour mettre en cache les actifs statiques et les réponses d'API plus près du client.
• Mise en cache des requêtes GraphQL : Mettez en cache les résultats des requêtes GraphQL en fonction de leur chaîne de requête et de leurs variables. Cela peut être particulièrement efficace pour les requêtes fréquemment exécutées. Apollo Server offre un support intégré pour la mise en cache des requêtes.

Lors de la mise en œuvre de la mise en cache, tenez compte des stratégies d'invalidation de cache pour vous assurer que les clients reçoivent des données à jour. Les stratégies courantes incluent :

• Expiration basée sur le temps : Définissez un temps d'expiration fixe pour les données mises en cache.
• Invalidation basée sur les événements : Invalidez le cache lorsque les données changent dans les services backend. Cela peut être réalisé à l'aide de webhooks ou de files d'attente de messages.

Surveillance et Observabilité

La surveillance et l'observabilité sont essentielles pour garantir la santé et les performances de votre Gateway API Frontend. Mettez en place une surveillance complète pour suivre les métriques clés telles que :

• Latence des requêtes : Le temps nécessaire pour traiter une requête.
• Taux d'erreur : Le pourcentage de requêtes qui aboutissent à des erreurs.
• Débit : Le nombre de requêtes traitées par unité de temps.
• Utilisation des ressources : Utilisation du CPU, de la mémoire et du réseau de la passerelle et des services backend.

Utilisez le traçage pour suivre les requêtes à mesure qu'elles traversent le système, en identifiant les goulots d'étranglement et les problèmes de performance. La journalisation fournit des informations précieuses sur le comportement de la passerelle et des services backend.

Les outils de surveillance et d'observabilité incluent :

• Prometheus : Un système de surveillance et d'alerte open-source.
• Grafana : Un outil de visualisation de données et de surveillance.
• Jaeger : Un système de traçage distribué open-source.
• Datadog : Une plateforme de surveillance et de sécurité pour les applications cloud.
• New Relic : Une plateforme d'intelligence numérique pour surveiller et améliorer les performances logicielles.

En mettant en œuvre une surveillance et une observabilité robustes, vous pouvez identifier et résoudre proactivement les problèmes, garantissant ainsi la fiabilité et les performances de votre Gateway API Frontend.

Conclusion

Une Gateway API Frontend construite avec la Fédération GraphQL ou le Schema Stitching peut considérablement simplifier l'accès aux données, améliorer les performances et enrichir l'expérience des développeurs dans les applications web modernes. La Fédération GraphQL offre une solution puissante et scalable pour composer des API GraphQL distribuées, tandis que le Schema Stitching propose une approche plus flexible pour combiner des schémas existants. En examinant attentivement les exigences spécifiques de votre application et les compromis entre ces techniques, vous pouvez choisir la meilleure approche pour construire une Gateway API Frontend robuste et efficace.

N'oubliez pas de mettre en œuvre une authentification et une autorisation appropriées, des stratégies de mise en cache, ainsi qu'une surveillance et une observabilité pour garantir la sécurité, les performances et la fiabilité de votre passerelle. En adoptant ces meilleures pratiques, vous pouvez libérer tout le potentiel de GraphQL et créer des applications web modernes qui offrent des expériences utilisateur exceptionnelles.