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.

Practice

1. What is the main purpose of the __resolveType function in GraphQL when using interfaces or unions?

easy

A. To fetch data from the database

B. To validate the query syntax before execution

C. To define new scalar types

D. To determine the specific object type to return for an abstract type

Solution

1. Step 1: Understand abstract types in GraphQL

   Abstract types like interfaces or unions can represent multiple object types.

2. Step 2: Role of __resolveType

   This function tells GraphQL which concrete type to use for the returned data.

3. Final Answer:

   To determine the specific object type to return for an abstract type -> Option D

4. Quick Check:

   Abstract type resolution = determine specific type [OK]

Hint: Remember: __resolveType picks the exact type [OK]

Common Mistakes:

• Confusing __resolveType with data fetching
• Thinking it validates query syntax
• Assuming it defines scalar types

2. Which of the following is the correct way to define a __resolveType function in a GraphQL resolver object?

easy

A. resolveType(obj) { return obj.typeName; }

B. __resolveType(obj) { return obj.kind; }

C. __resolveType(obj) { return obj.__typename; }

D. __resolveType(obj) { return obj.type; }

Solution

1. Step 1: Check the naming and return value

   The function must be named exactly __resolveType and return a string matching a type name.

2. Step 2: Match the returned value to the data field

   Commonly, the field __typename holds the type name, so returning obj.__typename is correct.

3. Final Answer:

   __resolveType(obj) { return obj.__typename; } -> Option C

4. Quick Check:

   Correct function name and return field = __resolveType(obj) { return obj.__typename; } [OK]

Hint: Function must be named exactly __resolveType [OK]

Common Mistakes:

• Using wrong function name like resolveType
• Returning incorrect property like type
• Returning undefined or wrong field

3. Given this resolver snippet for a union type:

__resolveType(obj) {
  if (obj.price) return 'Book';
  if (obj.author) return 'Author';
  return null;
}

What will be the resolved type for { price: 20, author: 'John' }?

medium

A. Book

B. Author

C. null

D. Error

Solution

1. Step 1: Check conditions in order

   The function first checks if obj.price exists, which is true here.

2. Step 2: Return first matching type

   Since obj.price is true, it returns 'Book' immediately without checking further.

3. Final Answer:

   Book -> Option A

4. Quick Check:

   First true condition returns 'Book' [OK]

Hint: Check conditions top to bottom, first match wins [OK]

Common Mistakes:

• Assuming it returns 'Author' because author field exists
• Thinking it returns null if multiple fields exist
• Expecting an error for multiple matches

4. You wrote this __resolveType function:

__resolveType(obj) {
  if (obj.kind === 'User') return 'User';
  if (obj.kind === 'Admin') return 'Admin';
}

But your GraphQL query returns null for the type. What is the likely problem?

medium

A. Function name should be resolveType without underscores

B. Missing a return statement for unmatched cases

C. The kind field does not exist in obj

D. GraphQL does not support __resolveType for interfaces

Solution

1. Step 1: Check function completeness

   The function lacks a return for cases when obj.kind is neither 'User' nor 'Admin'.

2. Step 2: Understand GraphQL behavior

   If no type is returned, GraphQL resolves the type as null, causing query issues.

3. Final Answer:

   Missing a return statement for unmatched cases -> Option B

4. Quick Check:

   Always return a type or null explicitly [OK]

Hint: Always return a type or null in __resolveType [OK]

Common Mistakes:

• Using wrong function name without underscores
• Assuming missing return defaults to a type
• Believing GraphQL doesn't support __resolveType

5. You have a GraphQL interface Vehicle implemented by types Car and Bike. Your __resolveType function is:

__resolveType(obj) {
  return obj.wheels === 4 ? 'Car' : 'Bike';
}

If an object has { wheels: 0 }, what will happen when querying this interface?

hard

A. It will resolve to 'Bike' because wheels is not 4

B. It will resolve to 'Car' because 0 is falsy

C. It will cause a runtime error due to invalid wheels

D. It will return null and cause query failure

Solution

1. Step 1: Evaluate the ternary condition

   The condition checks if obj.wheels === 4. For 0, this is false.

2. Step 2: Determine returned type

   Since condition is false, it returns 'Bike'.

3. Final Answer:

   It will resolve to 'Bike' because wheels is not 4 -> Option A

4. Quick Check:

   Condition false returns 'Bike' [OK]

Hint: Check exact equality, not truthiness, in __resolveType [OK]

Common Mistakes:

• Confusing falsy 0 with true condition
• Expecting runtime error for zero wheels
• Assuming null return causes failure