Bidirectional relationships in GraphQL - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is a bidirectional relationship in a database context?

A bidirectional relationship means two data entities are connected so that each can access the other directly, like two friends who both know each other.

beginner

How does a bidirectional relationship differ from a unidirectional relationship?

In a bidirectional relationship, both entities can reference each other. In a unidirectional relationship, only one entity knows about the other.

intermediate

In GraphQL, how do you represent a bidirectional relationship between two types?

You add fields in both types that reference each other, for example, a User type with a posts field and a Post type with an author field pointing back to User.

intermediate

Why are bidirectional relationships useful in data querying?

They allow easy navigation from one entity to the related entity in both directions, making queries more flexible and natural, like walking back and forth on a path.

advanced

What is a common challenge when implementing bidirectional relationships?

Avoiding infinite loops or circular references when querying data, which can happen if each side keeps asking for the other endlessly.

In a bidirectional relationship, which statement is true?

A Entities are unrelated.

B Only one entity can access the other.

C Neither entity can access the other.

D Both entities can access each other directly.

Bidirectional means both sides know about and can access each other.

In GraphQL, how do you create a bidirectional relationship between User and Post?

A Do not add any fields.

B Add only a posts field in User.

C Add a posts field in User and an author field in Post.

D Add only an author field in Post.

Both types need fields referencing each other to be bidirectional.

What problem can arise from bidirectional relationships in queries?

A Infinite loops or circular references.

B Data loss.

C Slower database writes only.

D No problems at all.

Bidirectional links can cause queries to loop endlessly if not handled carefully.

Which of these is NOT a benefit of bidirectional relationships?

A Automatic data validation.

B More flexible queries.

C Easy navigation between related data.

D Natural data modeling.

Bidirectional relationships help navigation and queries but do not automatically validate data.

If User has many Posts and Post belongs to one User, what kind of relationship is this?

A Unidirectional one-to-many.

B Bidirectional one-to-many.

C Many-to-many.

D No relationship.

User to Posts and Posts back to User is a bidirectional one-to-many relationship.

Explain what a bidirectional relationship is and why it is useful in databases.

Think about two friends who both know each other and can talk back and forth.

Describe how you would model a bidirectional relationship between two types in GraphQL.

Consider how each type points to the other in the schema.

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