Bidirectional relationships in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Querying a bidirectional relationship

Given a GraphQL schema where Author has a list of Book objects and each Book has a reference back to its Author, what will be the output of this query?

query {
  authors {
    name
    books {
      title
      author {
        name
      }
    }
  }
}

GraphQL

type Author {
  id: ID!
  name: String!
  books: [Book!]!
}

type Book {
  id: ID!
  title: String!
  author: Author!
}

# Sample data:
# Author: {id: "1", name: "Alice", books: [Book1, Book2]}
# Book1: {id: "101", title: "GraphQL Basics", author: Author}
# Book2: {id: "102", title: "Advanced GraphQL", author: Author}

A [{"name": "Alice", "books": [{"title": "GraphQL Basics", "author": {"name": "Alice"}}, {"title": "Advanced GraphQL", "author": {"name": "Alice"}}]}]

B [{"name": "Alice", "books": [{"title": "GraphQL Basics", "author": null}, {"title": "Advanced GraphQL", "author": null}]}]

C [{"name": "Alice", "books": [{"title": "GraphQL Basics"}, {"title": "Advanced GraphQL"}]}]

D [{"name": "Alice", "books": null}]

💡 Hint

Think about how the bidirectional link allows nested querying of author inside each book.

The query fetches authors, their books, and for each book, the author again. Because of the bidirectional relationship, the author inside each book is populated with the author's name.

🧠 Conceptual

intermediate

Understanding bidirectional relationships in GraphQL

Which statement best describes a bidirectional relationship in GraphQL schemas?

A Types are unrelated and cannot reference each other in queries.

B A type references itself recursively without involving other types.

C Two types reference each other, allowing queries to navigate from one to the other and back.

D A type has a list of scalar values only, without referencing other types.

💡 Hint

Think about how you can traverse data in both directions in a schema.

Bidirectional relationships mean two types have fields referencing each other, enabling queries to go from one type to the other and back.

📝 Syntax

advanced

Identify the syntax error in bidirectional schema definition

Which option contains a syntax error in defining a bidirectional relationship between Author and Book?

GraphQL

type Author {
  id: ID!
  name: String!
  books: [Book!]!
}

type Book {
  id: ID!
  title: String!
  author: Author!
}

A

type Author {
  id: ID!
  name: String!
  books: [Book]
}

type Book {
  id: ID!
  title: String!
  author: Author!
}

B

type Author {
  id: ID!
  name: String!
  books: [Book!]!
}

type Book {
  id: ID!
  title: String!
  author: Author!
}

C

type Author {
  id: ID!
  name: String!
  books: [Book!]!
}

type Book {
  id: ID!
  title: String!
  author: Author
}

D

type Author {
  id: ID!
  name: String!
  books: Book!
}

type Book {
  id: ID!
  title: String!
  author: Author!
}

💡 Hint

Check the type of the books field in Author. Should it be a list or a single object?

The books field should be a list of Book objects, not a single Book. Option D incorrectly defines it as a single Book without list brackets.

❓ optimization

advanced

Optimizing nested queries in bidirectional relationships

You have a bidirectional relationship between Author and Book. You want to fetch authors and their books but avoid redundant nested author data inside each book to reduce query size. Which query modification achieves this?

A Remove the nested <code>author</code> field inside <code>books</code> in the query.

B Add <code>@skip(if: true)</code> directive to the <code>author</code> field inside <code>books</code>.

C Use fragments to fetch <code>author</code> inside <code>books</code>.

D Fetch only <code>books</code> without any fields.

💡 Hint

Think about how to avoid fetching nested data you don't need.

Removing the nested author field inside books prevents fetching redundant author data, reducing query size and improving performance.

🔧 Debug

expert

Debugging infinite recursion in bidirectional GraphQL query

Consider this GraphQL query on a bidirectional schema:

query {
  authors {
    name
    books {
      title
      author {
        books {
          title
        }
      }
    }
  }
}

What problem will this query cause when executed?

A It will cause a syntax error due to nested fields.

B It will cause infinite recursion leading to a server error or timeout.

C It will return an empty list because of missing fields.

D It will return only the first author and their books without errors.

💡 Hint

Think about how the query keeps nesting author and books inside each other.

The query nests author inside books and then books inside author again, causing infinite recursion. This leads to server errors or timeouts.

Practice

1. What is the main purpose of bidirectional relationships in GraphQL schemas?

easy

A. To connect two types so you can query related data from both sides

B. To make the schema run faster by caching data

C. To encrypt data between client and server

D. To limit the number of queries a client can make

Solution

1. Step 1: Understand what bidirectional relationships do

   They link two types so you can access related data from either type easily.

2. Step 2: Compare options to this purpose

   Only To connect two types so you can query related data from both sides describes this linking and querying from both sides.

3. Final Answer:

   To connect two types so you can query related data from both sides -> Option A

4. Quick Check:

   Bidirectional relationships = connect types both ways [OK]

Hint: Think: Can I get related data from both types? That's bidirectional [OK]

Common Mistakes:

• Confusing bidirectional with performance optimization
• Thinking it encrypts data
• Assuming it limits queries

2. Which of the following is the correct way to define a bidirectional relationship between Author and Book types in GraphQL SDL?

easy

A. type Author { books: Book } type Book { author: [Author] }

B. type Author { books: [Author] } type Book { author: [Book] }

C. type Author { books: Book } type Book { author: Book }

D. type Author { books: [Book] } type Book { author: Author }

Solution

1. Step 1: Check the relationship types

   An author can have many books, so books should be a list of Book. Each book has one author, so author is a single Author.

2. Step 2: Match this to options

   Only type Author { books: [Book] } type Book { author: Author } correctly uses [Book] for books and Author for author.

3. Final Answer:

   type Author { books: [Book] } type Book { author: Author } -> Option D

4. Quick Check:

   List on many side, single on one side = type Author { books: [Book] } type Book { author: Author } [OK]

Hint: Many side uses list [], one side uses single type [OK]

Common Mistakes:

• Using single type where list is needed
• Swapping list and single types
• Using wrong type names

3. Given the following GraphQL schema snippet:

type User { posts: [Post] } type Post { author: User }

What will be the result of this query?

{ user { posts { author { id } } } }

medium

A. { "data": { "user": { "posts": [{ "author": { "id": "..." } }, ...] } } }

B. Syntax error due to missing fields

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

D. Runtime error because of circular reference

Solution

1. Step 1: Understand the schema and query

   User has posts, each post has an author. Query asks for user's posts and each post's author id.

2. Step 2: Predict the query result

   Since fields exist and are linked bidirectionally, the query returns posts with author ids nested properly.

3. Final Answer:

   { "data": { "user": { "posts": [{ "author": { "id": "..." } }, ...] } } } -> Option A

4. Quick Check:

   Bidirectional query returns nested data correctly [OK]

Hint: Bidirectional means nested data is accessible both ways [OK]

Common Mistakes:

• Thinking circular references cause runtime errors
• Assuming missing fields cause syntax errors
• Expecting null when data exists

4. You have this GraphQL schema:

type Category { products: [Product] } type Product { category: Category }

But your query for category { products { category { id } }} returns null for category inside products. What is the likely cause?

medium

A. The products field should not be a list

B. GraphQL does not support nested bidirectional queries

C. The category field in Product is not properly resolved or linked

D. The query syntax is invalid

Solution

1. Step 1: Analyze the schema and query

   Schema defines bidirectional links. Query asks for category's products and each product's category id.

2. Step 2: Identify why nested category is null

   If nested category is null, likely the resolver for category in Product is missing or incorrect.

3. Final Answer:

   The category field in Product is not properly resolved or linked -> Option C

4. Quick Check:

   Missing resolver causes null nested fields [OK]

Hint: Null nested fields often mean missing resolver functions [OK]

Common Mistakes:

• Assuming GraphQL can't do nested bidirectional queries
• Thinking list types cause nulls
• Blaming query syntax without error

5. You want to model a bidirectional relationship between Employee and Manager where each employee has one manager, and each manager can have many employees. Which schema correctly models this with bidirectional fields?

hard

A. type Employee { manager: Employee } type Manager { employees: [Manager] }

B. type Employee { manager: Manager } type Manager { employees: [Employee] }

C. type Employee { manager: Manager } type Manager { employees: Employee }

D. type Employee { manager: [Manager] } type Manager { employees: Employee }

Solution

1. Step 1: Understand the relationship

   Each employee has one manager (single), each manager has many employees (list).

2. Step 2: Match schema fields to this

   Employee's manager is a single Manager. Manager's employees is a list of Employee.

3. Final Answer:

   type Employee { manager: Manager } type Manager { employees: [Employee] } -> Option B

4. Quick Check:

   One-to-many bidirectional = single on one side, list on other [OK]

Hint: One side single type, other side list type for one-to-many [OK]

Common Mistakes:

• Swapping list and single types
• Using wrong types for fields
• Confusing employee and manager roles