Architecture
Diagramme d'architecture de fédération GraphQL avec une passerelle Apollo construisant des plans de requête et distribuant vers les sous-graphes Utilisateur, Produit et Avis, chacun possédant son schéma et sa base de données, avec assemblage des réponses en un résultat GraphQL unifié. Ce modèle représente l'approche GraphQL fédérée où plusieurs équipes développent et déploient indépendamment leurs sous-graphes tandis que les clients voient une API unifiée unique. Idéal pour les organisations mettant à l'échelle GraphQL à travers plusieurs équipes et services.
Code FlowZap complet
Client { # Client Application
n1: circle label:"GraphQL Query"
n2: rectangle label:"Send to Gateway"
n3: rectangle label:"Receive Unified Response"
n4: circle label:"Render UI"
n1.handle(right) -> n2.handle(left)
n2.handle(bottom) -> Gateway.n5.handle(top) [label="POST /graphql"]
n3.handle(right) -> n4.handle(left)
}
Gateway { # Apollo Federation Gateway
n5: rectangle label:"Parse GraphQL Query"
n6: rectangle label:"Build Query Plan"
n7: rectangle label:"Fan-Out to Subgraphs"
n8: rectangle label:"Merge Responses"
n9: rectangle label:"Return Unified Result"
n5.handle(right) -> n6.handle(left) [label="AST"]
n6.handle(right) -> n7.handle(left) [label="Execution Plan"]
n7.handle(bottom) -> Subgraphs.n10.handle(top) [label="User Fields"]
n7.handle(bottom) -> Subgraphs.n12.handle(top) [label="Product Fields"]
n7.handle(bottom) -> Subgraphs.n14.handle(top) [label="Review Fields"]
n8.handle(right) -> n9.handle(left) [label="Stitched"]
n9.handle(top) -> Client.n3.handle(bottom) [label="JSON"]
}
Subgraphs { # Federated Subgraphs
n10: rectangle label:"User Subgraph"
n11: rectangle label:"User Database"
n12: rectangle label:"Product Subgraph"
n13: rectangle label:"Product Database"
n14: rectangle label:"Review Subgraph"
n15: rectangle label:"Review Database"
n10.handle(right) -> n11.handle(left) [label="Query"]
n12.handle(right) -> n13.handle(left) [label="Query"]
n14.handle(right) -> n15.handle(left) [label="Query"]
n11.handle(top) -> Gateway.n8.handle(bottom) [label="User Data"]
n13.handle(top) -> Gateway.n8.handle(bottom) [label="Product Data"]
n15.handle(top) -> Gateway.n8.handle(bottom) [label="Review Data"]
}
Pourquoi ce workflow ?
A monolithic GraphQL server becomes a deployment bottleneck when multiple teams contribute to the same schema. GraphQL federation allows each team to independently develop, deploy, and scale their own subgraph while the gateway automatically composes them into a single unified API for clients.
Comment ça fonctionne
- Step 1: The client sends a single GraphQL query to the Apollo Federation Gateway.
- Step 2: The gateway parses the query and builds an execution plan identifying which subgraphs own which fields.
- Step 3: Parallel requests are fanned out to User, Product, and Review subgraphs.
- Step 4: Each subgraph queries its own database and returns its portion of the response.
- Step 5: The gateway stitches all subgraph responses into a single unified GraphQL result.
- Step 6: The composed response is returned to the client as if it came from a single API.
Alternatives
Schema stitching is an older approach that requires manual configuration. A monolithic GraphQL server is simpler but creates team coupling. REST with API composition achieves similar results without GraphQL. This template shows the federated approach for multi-team GraphQL.
Key Facts
| Template Name | Architecture de fédération GraphQL |
| Category | Architecture |
| Steps | 6 workflow steps |
| Format | FlowZap Code (.fz file) |
Modèles associés
Architecture
Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.
Architecture
Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.
Architecture
Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.
Architecture
Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.
Architecture
Diagramme d'architecture de migration Strangler Fig montrant le remplacement incrémental d'un monolithe legacy par de nouveaux microservices, utilisant une couche de routage pour répartir le trafic entre l'ancien et le nouveau système. Ce modèle représente la stratégie de migration éprouvée où les nouvelles fonctionnalités sont construites en microservices tandis que les endpoints legacy sont progressivement retirés. Essentiel pour les équipes modernisant des systèmes legacy sans réécriture risquée en big-bang.
Architecture
Diagramme d'architecture de découverte de services avec registre Consul ou Eureka, équilibrage de charge côté client, heartbeats de vérification de santé, et enregistrement/désenregistrement automatique des instances. Ce modèle visualise comment les microservices se localisent dynamiquement sans endpoints codés en dur, permettant une mise à l'échelle élastique et une infrastructure auto-réparatrice. Clé pour les équipes plateforme construisant une communication inter-services résiliente.