Running Federation with Cosmo: No Glue Code, No Surprises

#graphql #api #distributedsystems #apiarchitecture

If you caught Part 1, we walked through Federation with a food park analogy. This time, we're digging into what Cosmo actually does.

It’s not magic. Cosmo validates, routes, and coordinates your GraphQL subgraphs using the schema itself, so you get fewer bugs, fewer surprises, and no glue code to maintain.

🧠 Schema Composition: Catching Issues Before They Go Live

Every morning (or CI run), each team submits their subgraph schema to Cosmo. Cosmo composes them into a supergraph and checks for:

Duplicate type or field names
Ownership conflicts
Missing types or fields required by another subgraph

If anything’s off, composition fails and sends the schema back for review.

You’ll see exactly which service caused the issue and why—before it breaks your API.

📦 Query Planning: Routing Based on Ownership

Once everything’s composed, Cosmo uses the supergraph to plan how to resolve queries. Each field is mapped to the subgraph that owns it.

Let’s say a client sends:

graphql

query OrderSummary {
  sides { name }
  drinks { type }
}

Cosmo builds a query plan that looks like:

1. Send `sides` query to Fry Truck subgraph  
2. Send `drinks` query to Smoothie Truck subgraph  
3. Stitch together response and return to client

All of it is driven by schema metadata—no hand-coded routing rules, no guesswork.

⚠️ When Things Break: Cosmo Handles Fallback

Stuff goes wrong. Services go down. Fields error out. Cosmo doesn’t crash the whole response.

Here’s what it does instead:

Follows fallback rules if they’re defined
Retries if configured
Returns partial data and suppresses internal errors when needed

Fallback behavior is defined in the routing layer, not guessed at runtime.

📡 Real-Time Subscriptions: Subgraphs + Pub/Sub + Cosmo

Here’s the catch with subscriptions: they’re hard to federate.

Cosmo solves this with EDFS—Event-Driven Federated Subscriptions. Each subgraph sends events to a pub/sub system like NATS or Kafka. Cosmo listens to those streams, maps the events to the right GraphQL subscription using the composed schema and routing metadata, and filters out anything the client didn’t ask for.

No polling. No global fan-out. No manual wiring. Cosmo handles everything through the same schema-aware routing layer you’re already using for queries.