Software Architecture
The Dilemma of the Single GraphQL Server
When GraphQL was introduced as the superior successor to REST APIs, it promised a beautiful utopia for frontend developers: a single, uniform endpoint allowing them to query all necessary data across the entire organization via one powerful query. However, as adoption grew within enterprise organizations with microservices architectures, an organizational and technical scaling problem was encountered. To realize that one magical GraphQL endpoint, the entire enterprise structure (the schema) had to be crammed into a single monolithic GraphQL server or API Gateway. This resulted in dozens of development teams (e.g., the inventory team, the user team, and the billing team) all having to work in the same codebase to update their resolvers and types, leading to endless merge conflicts and release bottlenecks.
The solution to this architectural knot is GraphQL Federation, powered by the Apollo Supergraph (Apollo Federation) ecosystem.
Decentralized Development, Centralized Inquiry (Subgraphs)
With GraphQL Federation, the monolithic API is broken down into small, manageable pieces called ‘Subgraphs’. Each development team manages its own Subgraph (as a standalone GraphQL microservice). The e-commerce team builds and manages the Product subgraph. The logistics team is building the Stock subgraph. Each team can deploy its subgraph independently of the other teams, in their own programming language (one in Node.js, the other in Go or Java).
The magic lies at the center: the Apollo Router (or Gateway). The Router knows the schemas of all individual subgraphs and dynamically weaves them together into one gigantic ‘Supergraph’. If the frontend developer sends a query to the Router, for example: “Give me product X, including the description (from the Product subgraph), the current stock (from the Logistics subgraph), and the latest reviews (from the Review subgraph)”, The Router receives this query. The Router parses the query, sends lightning-fast requests in parallel to the three separate subgraphs, neatly combines the returned data into a single JSON object, and sends it back to the frontend. The frontend is completely unaware that the data originates from three different microservices.
Connecting Entities Across Borders
What makes Federation powerful is the ability to entities (such as a User) to expand across borders. The Account team defines the basic User type (with ID and name). The Review team can do the same in *their* subgraph User expand type with a field latestReviews. The teams do not need to know each other’s code; by using directives such as @key and @extend In their GraphQL schema, the router automatically understands how these fields should be mapped based on the User ID.
Schema Registry and Observability
Because dozens of subgraphs can modify the schema, governance is crucial. Apollo offers a central Schema Registry. When a team performs an update (e.g., they remove a field from their subgraph), the registry immediately analyzes (during the CI/CD pipeline) whether this removal will break active queries of frontend applications (Schema Checks). If this is the case, deployment is blocked. This prevents downtime. GraphQL Federation has become the standard for large enterprises (such as Netflix, Booking.com, and Walmart) to combine the agility of microservices with the convenience of a single, unified data API. For a broader perspective on microservices, read AG Connect.
Next: Docker vs. Podman: The Transition to Daemonless and Rootless Containers
