📖 Scenario: You are building a simple social network database where users can follow each other. Each user should know who they follow and who follows them.
🎯 Goal: Create a GraphQL schema that models users with bidirectional relationships: each user has a list of users they follow and a list of users who follow them.
📋 What You'll Learn
Define a User type with id and name fields
Add a follows field to User that lists users this user follows
Add a followers field to User that lists users who follow this user
Create a root Query type to fetch all users
💡 Why This Matters
🌍 Real World
Social networks and apps often need to model relationships where users follow each other, requiring bidirectional links.
💼 Career
Understanding bidirectional relationships in GraphQL is important for backend developers building APIs for social platforms and connected data.
Progress0 / 4 steps
1
Define the User type with basic fields
Define a GraphQL User type with fields id of type ID! and name of type String!.
GraphQL
Hint
Start by defining a type User with id and name fields.
2
Add the follows field to User
Add a field called follows to the User type. It should be a list of User objects, non-nullable, and the list itself should be non-nullable (use [User!]!).
GraphQL
Hint
The follows field should be a list of users this user follows.
3
Add the followers field to User
Add a field called followers to the User type. It should be a list of User objects, non-nullable, and the list itself should be non-nullable (use [User!]!).
GraphQL
Hint
The followers field should be a list of users who follow this user.
4
Create the Query type to fetch all users
Define a root Query type with a field called users that returns a non-nullable list of non-nullable User objects (use [User!]!).
GraphQL
Hint
The Query type should allow fetching all users with the users field.
Practice
(1/5)
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
Step 1: Understand what bidirectional relationships do
They link two types so you can access related data from either type easily.
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.
Final Answer:
To connect two types so you can query related data from both sides -> Option A
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
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.
Step 2: Match this to options
Only type Author { books: [Book] } type Book { author: Author } correctly uses [Book] for books and Author for author.
Final Answer:
type Author { books: [Book] } type Book { author: Author } -> Option D
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 }
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
Step 1: Analyze the schema and query
Schema defines bidirectional links. Query asks for category's products and each product's category id.
Step 2: Identify why nested category is null
If nested category is null, likely the resolver for category in Product is missing or incorrect.
Final Answer:
The category field in Product is not properly resolved or linked -> Option C
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
Step 1: Understand the relationship
Each employee has one manager (single), each manager has many employees (list).
Step 2: Match schema fields to this
Employee's manager is a single Manager. Manager's employees is a list of Employee.
Final Answer:
type Employee { manager: Manager } type Manager { employees: [Employee] } -> Option B
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
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.