Breaking the Subgraph Barrier: Why GraphQL Federation Needs gRPC

GraphQL Federation has helped teams scale their APIs by splitting them into composable Subgraphs. But after working with Federation deeply, we started asking a harder question:

What if Subgraphs didn’t have to speak GraphQL at all?

We realized the protocol between the Router and backend services was holding us back from performance, from type safety, and from innovation.

So we replaced it. The Cosmo Router now supports a new model: keep GraphQL at the edge, and run your Subgraphs as gRPC services behind the scenes.

Here’s why we made that shift, and what it unlocks.

For the original post, visit WunderGraph’s blog.

GraphQL Subgraphs Add More Complexity Than They Solve

Let’s walk through the problems we ran into — and why a gRPC-based model solves them better.

1. Subgraphs Aren’t Truly Type Safe

GraphQL’s strength is its type system. But in Federation, entity resolution uses _Any inputs and runtime casting via __typename.

Subgraphs like this:

type User @key(fields: "id") {
  id: ID!
  name: String!
}

Receive requests like this:

{
  "representations": [
    { "__typename": "User", "id": "1" },
    { "__typename": "User", "id": "2" }
  ]
}

If your Subgraph resolver mismatches the SDL, you find out at runtime — maybe in production. Frameworks don’t enforce strict typing between your schema and implementation.

By contrast, gRPC enforces schema correctness at code generation time. We eliminate a whole category of bugs.

2. Subgraphs Require Manual Data Loader Logic

N+1 fetch problems are common in GraphQL. Subgraph frameworks leave it up to you to batch and cache your lookups.

In Cosmo, the Router already handles batching, caching, and query planning. When you move data fetching to gRPC services, you get these optimizations by default.

3. GraphQL as a Transport Layer Adds Overhead

GraphQL is powerful, but heavy. In a Subgraph model, each request goes through:

• Parsing
• Normalization
• Validation
• Planning
• Execution

That’s fine at the Router level, but doing it in every Subgraph introduces latency, variability, and performance risks (especially when teams choose different languages or frameworks).

gRPC is simpler and faster. We can eliminate entire stages of processing from the Subgraph path.

4. The Federation Ecosystem Is Bottlenecked by Apollo

Apollo controls the Subgraph spec, framework updates, and rollout timelines. If your tooling depends on their implementation pace (or their business model), you’re locked in.

We’ve seen this impact open source support, delay adoption of new Federation features, and limit innovation across the community.

By removing GraphQL from the Subgraph layer entirely, we remove that bottleneck. Every language that supports gRPC can implement new Federation features the moment the Router does.

What the gRPC Federation Model Looks Like

Let’s say you start with a familiar SDL:

type User @key(fields: "id") {
  id: ID!
  name: String!
}

You compile that into a gRPC service:

syntax = "proto3";
package service;

service UsersService {
  rpc LookupUserById(LookupUserByIdRequest) returns (LookupUserByIdResponse) {}
}

message LookupUserByIdRequestKey {
  string id = 1;
}

message LookupUserByIdRequest {
  repeated LookupUserByIdRequestKey keys = 1;
}

message LookupUserByIdResponse {
  repeated User result = 1;
}

message User {
  reserved 2 to 3;
  string id = 1;
  string name = 4;
}

Then you register the service with the Cosmo Router using a config like:

subgraphs:
  - name: users
    routing_url: localhost:4011
    grpc:
      schema_file: ./schema.graphql
      proto_file: ./generated/service.proto
      mapping_file: ./generated/mapping.json

The Router handles the rest. Your Subgraph now runs as a typed, batch-optimized gRPC service.

Federation Without the Friction

We’re not removing GraphQL, we’re moving it to the boundary where it matters most: between the client and the Router.

Under the hood, gRPC makes Subgraphs faster, safer, and easier to evolve. Developers don’t need to rewrite their workflows. But the system underneath is stronger.

If you want to dive deeper into how this works technically, read The Next Generation of GraphQL Federation Speaks gRPC.

To try it yourself, head to the Cosmo gRPC Service Quickstart.

And if you have thoughts, questions, or feedback, join us on Discord. We’d love to hear what you think.