Should You Use GraphQL Schema Stitching?

Why bother with GraphQL schema stitching? It’s a way to combine multiple remote schemas into one, but it’s often more trouble than it’s worth.

Why it breaks

I’ve worked on systems where stitching felt like a magic bullet. You define a proxy, point it at your services, and boom, you have one giant graph. Except, your performance tanks. Now you’re dealing with the n+1 problem across network boundaries. It’s a mess. Every time a downstream service changes, your proxy might break, and debugging that logic across three different services is a nightmare (especially when you’re on call at 2 AM).

Some might say, “But my team needs a single source of truth for the frontend.” Sure, that’s a fair point. If you have a small team and a handful of microservices, stitching works. I’m not saying it’s never valid. It’s just that I’ve seen it lead to tight coupling that kills development speed later on.

Consider the alternative

I prefer using Federation. It’s designed for this. You use directives to share types, and the gateway handles the heavy lifting without manually stitching every resolver. It’s cleaner. If you aren’t ready to invest in Apollo Federation or similar tools, maybe just build a separate API for your specific needs instead of trying to force a unified schema.

Here is what stitching looks like at its simplest level:

1
const schema = mergeSchemas({
2
  schemas: [serviceOneSchema, serviceTwoSchema],
3
  onTypeConflict: (left, right) => left
4
});

It looks clean, right? That’s the trap. As soon as you need complex data merging or custom scalar support, this snippet turns into a configuration hell. I’m not entirely sure if stitching has a place in large organizations anymore, given how much better Federation has become. Does anyone actually enjoy debugging proxy resolver logic after the third microservice is added?