Compare and contrast schema stitching and Apollo Federation as strategies for composing GraphQL APIs from microservices.
Node.js interview question for Advanced practice.
Answer
Both schema stitching and Apollo Federation solve the same problem: creating a unified GraphQL API gateway from multiple underlying GraphQL services. However, they approach it differently. Schema Stitching: This is an imperative approach. You create a separate gateway server that is explicitly aware of the downstream services. The gateway is responsible for fetching the schemas, merging them, and adding explicit 'stitching resolvers' to define relationships between types from different services. The gateway owns the logic for how services connect. Pros: More flexible; you have full control in the gateway to transform and manipulate schemas. Cons: Can become complex and fragile. The gateway becomes a central point of logic that must be updated whenever downstream services change how they relate to each other. Apollo Federation: This is a declarative approach. Each underlying service (called a 'subgraph') annotates its schema with special directives (@key, @extends, etc.) to declare how its types relate to types in other services. A gateway (like the Apollo Router) ingests these schemas and automatically composes the unified graph and a query plan. The services themselves own their relationships. Pros: More scalable and robust. It decentralizes the schema definition, removing the gateway as a logic bottleneck. Better developer experience as teams can define their service's connections independently. Cons: Less flexible than stitching; you are constrained by the federation specification. Requires using Apollo's tooling. Conclusion: For new projects, Apollo Federation is almost always the recommended approach due to its scalability and better separation of concerns.
Explanation
Apollo Federation was designed by Apollo to overcome some of the challenges and complexities encountered with schema stitching.