Shared types across subgraphs in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the purpose of shared types in GraphQL subgraphs?

In a GraphQL federated architecture, why do we use shared types across subgraphs?

A To prevent any subgraph from accessing types defined in other subgraphs.

B To duplicate type definitions in each subgraph for faster query execution.

C To allow multiple subgraphs to reference the same type and ensure consistent data representation.

D To enforce that each subgraph has completely unique types with no overlap.

💡 Hint

Think about how multiple teams might work on different parts of a graph but need to share common data structures.

Shared types allow different subgraphs to refer to the same type, which helps keep data consistent and enables the gateway to stitch the schema correctly.

❓ query_result

intermediate

What is the output of this federated schema query?

Given two subgraphs sharing a User type with a @key directive, what will this query return?

query {
  user(id: "123") {
    id
    name
    email
  }
}

GraphQL

Subgraph A defines User with fields id, name and @key(fields: "id").
Subgraph B extends User with field email.
The gateway composes the schema and runs the query above.

A { "errors": [ { "message": "Field 'email' not found on type 'User'" } ] }

B { "data": { "user": { "id": "123", "name": "Alice", "email": "[e-mail]" } } }

C { "data": { "user": null } }

D { "data": { "user": { "id": "123", "name": "Alice" } } }

💡 Hint

Remember that the gateway merges fields from all subgraphs that share the same key.

The gateway merges the User type from both subgraphs using the @key directive, so the query returns all fields including email.

📝 Syntax

advanced

Which subgraph schema snippet correctly shares a type with a @key directive?

Identify the valid GraphQL schema snippet that correctly defines a shared Product type with a @key directive for federation.

A

type Product @key(fields: "upc") {
  upc: String!
  name: String
  price: Float
}

B

type Product @key(fields: upc) {
  upc: String!
  name: String
  price: Float
}

C

type Product @key(fields: "upc") {
  upc: String
  name: String
  price: Float
}

D

type Product @key(fields: "upc") {
  upc: Int!
  name: String
  price: Float
}

💡 Hint

Check the syntax for the @key directive and the type of the key field.

The @key directive requires the fields argument as a string. The key field must be non-nullable and the type must match usage. Option A correctly uses String! and quotes around upc.

❓ optimization

advanced

How to optimize resolving shared types across subgraphs?

When multiple subgraphs share a type, what is an effective way to optimize query performance at the gateway?

A Fetch all fields from all subgraphs regardless of query selection to cache data.

B Duplicate all shared types in each subgraph to reduce gateway overhead.

C Disable schema stitching to speed up query execution.

D Use entity resolvers to fetch only required fields from each subgraph and avoid over-fetching.

💡 Hint

Think about how to minimize data transfer and processing by fetching only what is needed.

Entity resolvers allow the gateway to request only the fields needed from each subgraph, reducing data transfer and improving performance.

🔧 Debug

expert

Why does this federated query fail with a 'Cannot find key fields' error?

Given this subgraph schema snippet:

extend type Review @key(fields: "id") {
  id: ID!
  body: String
}

And this query:

query {
  review(id: "r1") {
    id
    body
  }
}

Why does the gateway return an error: Cannot find key fields for type 'Review'?

A Because the base <code>Review</code> type is not defined in any subgraph, only extended.

B Because the <code>@key</code> directive is missing the correct field name.

C Because the <code>id</code> field is not marked as non-nullable.

D Because the query uses <code>review</code> instead of <code>reviews</code>.

💡 Hint

Consider what it means to extend a type without defining it first.

Extending a type requires that the base type be defined in at least one subgraph. Here, Review is only extended but never defined, so the gateway cannot find key fields.