GraphQL 联邦架构

Architecture

GraphQL 联邦架构图，Apollo 网关构建查询计划并扇出到用户、产品和评论子图，每个子图拥有自己的模式和数据库，响应拼接为统一的 GraphQL 结果。该模板模拟联邦 GraphQL 方法，多个团队独立开发和部署其子图，而客户端看到单一统一的 API。适合跨多个团队和服务扩展 GraphQL 的组织。

下载 .fz 文件

完整 FlowZap 代码

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"]
}

为什么需要这个工作流？

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.

工作原理

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.

替代方案

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	GraphQL 联邦架构
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)