Abstract type resolution in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Output of a GraphQL query with interface type

Given the following GraphQL schema snippet:

interface Character {
  id: ID!
  name: String!
}
type Human implements Character {
  id: ID!
  name: String!
  homePlanet: String
}
type Droid implements Character {
  id: ID!
  name: String!
  primaryFunction: String
}

And this query:

{
  characters {
    id
    name
    ... on Human {
      homePlanet
    }
    ... on Droid {
      primaryFunction
    }
  }
}

Assuming the data contains one Human and one Droid, what is the shape of the returned data?

A {"characters":[{"id":"1","name":"Luke","primaryFunction":"Astromech"},{"id":"2","name":"R2-D2","homePlanet":"Tatooine"}]}

B {"characters":[{"id":"1","name":"Luke"},{"id":"2","name":"R2-D2"}]}

C {"characters":[{"id":"1","name":"Luke","homePlanet":"Tatooine"},{"id":"2","name":"R2-D2","primaryFunction":"Astromech"}]}

D {"characters":[{"id":"1","name":"Luke","homePlanet":null},{"id":"2","name":"R2-D2","primaryFunction":null}]}

💡 Hint

Look at the inline fragments ... on Human and ... on Droid to see which fields are included for each type.

The query uses inline fragments to select fields specific to each implementing type of the Character interface. The Human has homePlanet and the Droid has primaryFunction. The result includes these fields only for the matching types.

🧠 Conceptual

intermediate

Understanding abstract type resolution in GraphQL

In GraphQL, when a query requests a field of an abstract type (interface or union), how does the server determine which concrete type to use for each result item?

A The server uses the __typename field or a custom resolveType function to identify the concrete type for each item.

B The client specifies the concrete type explicitly in the query, so the server does not need to resolve it.

C The server always returns the first type listed in the schema for the abstract type.

D The server randomly picks a concrete type for each item when resolving abstract types.

💡 Hint

Think about how GraphQL knows which fields to return for each item when the type is abstract.

The GraphQL server uses the __typename field or a resolveType function defined in the schema to determine the concrete type of each item implementing an interface or union. This allows it to return the correct fields for that type.

📝 Syntax

advanced

Identify the syntax error in this GraphQL fragment for abstract type resolution

Consider this GraphQL query fragment:

{
  search(text: "robot") {
    ... on Human {
      name
      homePlanet
    }
    ... Droid {
      name
      primaryFunction
    }
  }
}

What is the syntax error in this fragment?

A The fields inside the fragments must be wrapped in braces.

B The fragment on Human should be a named fragment, not inline.

C The search field cannot have inline fragments.

D The inline fragment on Droid is missing the keyword 'on'.

💡 Hint

Check the syntax for inline fragments in GraphQL.

Inline fragments on abstract types require the keyword on before the type name. The fragment ... Droid is missing on and should be ... on Droid.

🔧 Debug

advanced

Why does this GraphQL query return null for type-specific fields?

Given this schema:

interface Animal {
  id: ID!
  name: String!
}
type Dog implements Animal {
  id: ID!
  name: String!
  breed: String
}
type Cat implements Animal {
  id: ID!
  name: String!
  livesLeft: Int
}

And this query:

{
  animals {
    id
    name
    ... on Dog {
      breed
    }
    ... on Cat {
      livesLeft
    }
  }
}

The response returns null for breed and livesLeft fields for all animals. What is the most likely cause?

A The server's resolveType function is not implemented or returns null, so type-specific fields are not resolved.

B The query is missing the __typename field, so the client cannot distinguish types.

C The animals field does not return any data, so all fields are null.

D The schema does not allow inline fragments on interfaces.

💡 Hint

Think about how the server knows which concrete type each item is.

If the server does not implement or returns null from the resolveType function for the interface, it cannot determine the concrete type of each item. As a result, type-specific fields in inline fragments return null.

❓ optimization

expert

Optimizing abstract type resolution for large GraphQL queries

You have a GraphQL query that fetches a large list of items of an interface type with many inline fragments for different implementations. The query is slow because the server resolves the concrete type for each item individually. Which approach can optimize abstract type resolution performance?

A Increase the query timeout to allow more time for type resolution.

B Batch resolve types by grouping items by type in the resolveType function to reduce overhead.

C Use client-side caching to avoid repeated queries for the same data.

D Remove inline fragments and query only common interface fields to avoid type resolution.

💡 Hint

Think about how to reduce repeated work on the server when resolving types.

Batching type resolution by grouping items of the same type reduces the number of calls to resolveType and improves performance. This is better than resolving each item individually.