How do I aggregate multiple APIs with GraphQL?

Aggregating multiple APIs behind one GraphQL endpoint is what GraphQL Federation is built for. Here's how it works and how to approach it:

The core architecture

Your unified GraphQL layer is called a supergraph, made up of individual services called subgraphs

• A router (or gateway) sits between clients and your subgraphs — clients only ever query the router, and it intelligently orchestrates calls across the underlying APIs to return one unified response Different subgraphs can use different server implementations and even different programming languages, as long as each is federation-compatible

• For performance and security, only the router should query the constituent APIs directly — clients never talk to subgraphs themselves

What can be aggregated

• Federation isn't limited to GraphQL-to-GraphQL — your supergraph can combine GraphQL APIs, REST APIs, and other data sources Apollo Connectors lets you integrate REST APIs into a federated graph declaratively, using GraphQL directives, without having to hand-write a wrapping subgraph

Steps to build it

• Identify service boundaries — define clear domain boundaries (e.g., users, products, orders) that map to how your teams/services are actually organized

• Design each subgraph schema — each team builds their own schema representing their domain

• Mark shared entities with @key — this directive specifies which fields identify a type across subgraphs, so the router knows how to fetch and stitch it. For example, both a "products" and "reviews" subgraph might define Product with a shared id field, each contributing different fields to it Implement __resolveReference in each subgraph so the router can look up an entity by its key from that subgraph

• Extend types across subgraphs to add fields without one subgraph owning the entire entity — e.g., a reviews subgraph can extend Product with a reviews field it owns

• Deploy a gateway/router that performs schema composition — validating and merging all subgraph schemas into one supergraph, then handling query planning at runtime Use a schema registry to manage composition and catch breaking changes before they ship

Use DataLoader in your entity resolvers to batch reference lookups across subgraphs and avoid N+1 problems at the federation layer too

When to actually use it

Federation is valuable specifically when multiple teams need to own different parts of an API independently, or when you're aligning API structure with microservices/domain-driven design

• It requires real infrastructure investment: a dedicated team to manage the gateway and schema registry, plus governance to keep teams aligned

• Notably, Meta — where GraphQL originated — has stuck with a monolithic GraphQL API since 2012, while Netflix, Expedia Group, Volvo, and Booking.com have adopted federation. The common advice: start with a single monolithic GraphQL server and migrate to federation only once you actually need the team-independence it provides, not preemptively

• Alternative: schema stitching

• This predates federation and combines multiple schemas at runtime, but requires much more custom glue logic and can introduce performance issues if done carelessly — federation is now generally preferred for anything at scale