A complete GraphQL Federation stack: What you need (and what you don't)

As GraphQL adoption grows, so does the complexity of the infrastructure behind it — especially when your API spans teams, services, and domains. Federation solves the problem of scaling GraphQL across microservices. But what do you really need to build and run a production-ready federated GraphQL stack? In this guide, we’ll break down the core components of a GraphQL Federation stack, when they’re essential, and how modern platforms like Grafbase remove many of the traditional burdens.

GraphQL Federation is a powerful architectural pattern that lets you:

• Split your API into independent subgraphs (services)
• Compose them into a single, unified schema (the supergraph)
• Scale teams and services independently — without a monolithic API

But building and maintaining a federated stack traditionally comes with operational overhead.

Let’s break it down.

To deploy GraphQL Federation in production (especially with Apollo Federation), teams typically need to build and manage:

Individual GraphQL services that define and own a portion of the schema.

Each subgraph is usually:

• Owned by a specific team or domain (e.g. users, products)
• Deployed independently Each defining how it composes with other subgraphs, using federation directives (@key, @requires, etc.)

A process to merge subgraph schemas into a single supergraph schema.

With Grafbase, this happens automatically when you publish a subgraph, run schema checks or manually run grafbase compose.This step is essential for validating schema compatibility and, with schema checks, catching breaking changes before they’re deployed. Grafbase makes it seamless and declarative.

The router that:

• Accepts incoming client queries
• Parses and validates against the composed supergraph
• Optionally, enforces rate limits, query complexity, authentication, authorization and much more.
• Produces a query plan that optimizes the number and ordering of subgraph calls, batching entity and data requirements resolution.
• Executes that plan as efficiently as possible

This component is stateless, but it is a central point of failure and must be scaled and monitored like any critical service.

Federated systems need a consistent identity model across all services:

• Authentication should be applied at the gateway to establish the user's identity.
• Fine-grained authorization must be handled at the gateway or subgraph layer, depending on your architecture and trust boundaries.

Grafbase provides robust support for both, with extensible mechanisms (for example for JWT-based auth) and contextual access control.

Each subgraph is typically deployed as an independent GraphQL service with its own CI/CD pipeline.

Federation is designed to support independent schema evolution — most changes can be made without coordination, as long as composition checks pass.

With Grafbase, schema updates are published declaratively via the CLI.

Distributed systems need distributed observability.

You’ll likely need:

• Logging for each service
• Tracing to follow the call stack from the gateway to subgraphs, and potentially further upstream services
• Gateway-level performance insights. Grafbase Gateway can export GraphQL specific OpenTelemetry metrics in addition to traces.

Grafbase is designed to offer you the option to collapse the federation stack into just the gateway, alleviating the need for dedicated GraphQL services for subgraphs that just expose a service that could be contacted directly, like a REST API, a NATS server or a Postgres database. Subgraphs that have a name and a GraphQL schema, but are not backed by a live GraphQL service are called virtual subgraphs.

Here’s how virtual subgraphs simplify the picture we painted above:

Grafbase supports both traditional and virtual subgraphs — giving teams the flexibility to adopt Federation without the operational overhead.

With virtual subgraphs, you don’t need to deploy separate GraphQL services. Instead, you define your subgraphs declaratively as GraphQL schemas using extensions, and push them using the Grafbase CLI. Behind the scenes, Grafbase:

• Composes your supergraph automatically in the schema registry
• With that schema, the gateway can plan, optimize and execute queries against the federated graph, exposing a single unified GraphQL endpoint to clients

A virtual subgraph will make use of extensions as resolvers. Multiple extensions can live in the same subgraph. Here is a simple example:

schema
    @link(
        url: "https://specs.grafbase.com/composite-schemas/v1"
        import: ["@derive"]
    )
    @link(
        url: "https://grafbase.com/extensions/rest/0.4.1"
        import: ["@restEndpoint", "@rest"]
    )
    @restEndpoint(name: "factories-api", baseURL: "http://localhost:4001")
{
  query: Query
}

type Query {
  factories: [Factory!]!
    @rest(
      method: GET
      endpoint: "factories-api"
      path: "/factories"
      selection: "."
    )
}

type Factory {
  lat: Float!
  lng: Float!
  productId: ID!
  product: Product! @derive
}

type Product @key(fields: "id") {
  id: ID!
}

This model is ideal when your gateway talks directly to non-GraphQL services, such as REST APIs, databases, or internal microservices, and you want to expose them through a federated GraphQL layer without managing subgraph infrastructure.

You still get all the benefits of Federation like modular APIs, team-level schema ownership, optimized query plans with declarative data requirements and joins between subgraphs, and a unified developer experience, but without needing to host and operate GraphQL servers for every subgraph. That can add up to significant savings in infrastructure costs, in addition to the savings from using the highest performance federation gateway.

For teams that already have GraphQL services in production, Grafbase can federate those too, making it easy to mix and match subgraph types in the same supergraph.

For scale-ups and enterprise teams, adopting GraphQL often means integrating with a wide range of existing systems, many of which aren’t GraphQL-native.

Grafbase’s support for virtual subgraphs makes this transition significantly easier. Instead of standing up and maintaining separate GraphQL services, you can declaratively model subgraphs that proxy existing REST APIs, databases, or internal services — no extra infrastructure required.

This gives platform and infra teams a faster, more reliable way to:

• Roll out a federated architecture incrementally
• Avoid costly coordination across teams
• Provide a unified GraphQL layer over legacy and modern systems alike

You still get all the benefits of Federation like modularity, autonomy, and a single API, but without the operational complexity of deploying and managing N GraphQL services.

GraphQL Federation is a powerful pattern, but the traditional stack can be overkill for many teams. Grafbase streamlines everything: composition, deployment, routing, and security — no custom infrastructure needed.

If you're exploring federation, start with what matters: your API and your schema. Let Grafbase handle the rest.