Federation and Stitching in GraphQL Quiz Quiz

Explore key concepts of GraphQL Federation and Schema Stitching with this focused quiz. Assess your understanding of distributed schemas, gateway roles, schema composition, and integration methods commonly used in modern GraphQL architecture.

1. Identifying Gateway Responsibilities

   Which primary responsibility does the gateway have when implementing GraphQL Federation to connect separate services?

   1. Combining schemas from multiple services into a unified graph
   2. Directly managing subservice databases
   3. Storing and versioning all schema definitions
   4. Centrally executing business logic for all requests

   Explanation: In GraphQL Federation, the gateway's main role is to compose the schemas provided by multiple services into a single, unified graph that clients can query. It does not store or version schemas (this is usually managed by each service). The gateway does not handle business logic execution for the subservices; responsibilities remain with the original services. It also does not manage or interact with the underlying databases directly.

2. Understanding Schema Stitching

   When using schema stitching, what is the purpose of defining a 'merge' configuration or stitching directives in your configuration?

   1. To automate combining types and resolve overlapping fields between services
   2. To control rate limiting across individual endpoints
   3. To generate mock resolvers for federated services
   4. To create aliases for every field in the schema

   Explanation: Stitching directives and merge configurations help automatically identify overlapping fields or types and merge them properly between different schemas, ensuring smooth integration. They are not used for rate limiting, which is handled separately. Mock resolver generation is unrelated to the stitching process, and field aliases can be defined but are not the core function of stitching directives.

3. Service Independence in Federated Graphs

   In a federated GraphQL architecture with Review, User, and Product subgraphs, how does each service commonly maintain independence?

   1. Each depends directly on another subservice’s internal database
   2. All share a common resolver function for user authentication
   3. Each exposes only its part of the schema and resolves only its own types
   4. Every service re-implements the entire schema but ignores unrelated types

   Explanation: Each federated service defines its segment of the overall schema, ensuring boundaries are respected and redundancy is minimized. Common resolver functions across all services would create tight coupling, reducing independence. Re-implementing the full schema in every subservice is inefficient and unnecessary. Direct database dependencies between subservices break modularity and increase complexity.

4. Comparing Federation and Stitching

   Which aspect distinguishes GraphQL Federation from traditional schema stitching techniques?

   1. Stitching guarantees no duplication of scalar fields across schemas
   2. Federation enables declarative service boundaries and reference resolution across services
   3. Stitching automatically infers resolver logic for all combined types
   4. Federation requires all services to be written in the same programming language

   Explanation: Federation stands out by allowing you to declare clear ownership of types and by supporting reference resolution for entities across subservices. Stitching does not infer resolver logic automatically; developers must provide necessary merges. Federation does not require language uniformity. Stitching does not automatically prevent scalar field duplication—care must be taken when combining schemas.

5. Handling Field Conflicts During Schema Integration

   What is a recommended strategy for handling conflicting field names when stitching multiple GraphQL schemas together?

   1. Ignore conflicts and let the most recently imported schema override
   2. Rename conflicting fields using aliases during the merge process
   3. Remove all duplicated fields without exception
   4. Merge fields by combining all possible values into an array

   Explanation: Renaming conflicting fields or applying aliases helps maintain clarity and avoids runtime errors during schema stitching. Removing all duplicates may result in data loss. Ignoring conflicts or arbitrarily overriding with the latest schema is risky and unpredictable. Automatically merging all values into arrays can lead to confusion and unintended results.