Schema-first development in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

What is the main advantage of schema-first development in GraphQL?

Consider you are building a GraphQL API. What is the primary benefit of defining the schema before writing any resolver code?

A It forces the API to use REST endpoints internally.

B It automatically generates database tables without any additional setup.

C It eliminates the need for writing any resolver functions.

D It allows frontend and backend teams to agree on data structure early, improving collaboration.

💡 Hint

Think about how defining the shape of data first helps teams work together.

Schema-first development means you design the API's data types and queries upfront. This helps frontend and backend developers understand and agree on the data format early, making collaboration smoother.

❓ query_result

intermediate

What is the output of this GraphQL query given the schema?

Given the schema below, what will be the result of the query?

type Query {
  book(id: ID!): Book
}

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

Query:
{
  book(id: "1") {
    title
    author
  }
}

GraphQL

Assume the data source has a book with id "1", title "1984", and author "George Orwell".

A { "data": { "book": { "title": "1984", "author": "George Orwell" } } }

B { "data": { "book": { "id": "1", "title": "1984" } } }

C { "data": { "book": null } }

D { "errors": [ { "message": "Field 'author' not found" } ] }

💡 Hint

Look at the query fields and the schema's Book type.

The query asks for title and author of the book with id "1". Since the data source has this book, the response includes both fields under data.book.

📝 Syntax

advanced

Identify the syntax error in this GraphQL schema definition

Which option contains the syntax error in the schema below?

type User {
  id: ID!
  name: String!
  email: String!
  friends: [User]
}

type Query {
  user(id: ID!): User
}

GraphQL

Assume the schema is used in a GraphQL server.

A There is no syntax error; the schema is valid.

B The 'friends' field should be '[User]!' to indicate the list is non-null.

C The 'friends' field should be '[User!]!' to indicate a non-null list of non-null Users.

D The 'friends' field should be '[User!]' instead of '[User]'.

💡 Hint

Check the GraphQL list and nullability syntax rules.

The schema is valid. The 'friends' field is a list of User objects that can be null or contain nulls. This is allowed syntax in GraphQL.

❓ optimization

advanced

How to optimize resolver performance in schema-first GraphQL?

You notice your GraphQL API is slow because many resolvers fetch data separately. Which approach best improves performance?

A Remove the schema and write raw SQL queries instead.

B Add more fields to the schema to reduce the number of queries.

C Use data loader pattern to batch and cache database requests in resolvers.

D Use REST endpoints inside resolvers to fetch data.

💡 Hint

Think about how to reduce repeated database calls in resolvers.

Data loader batches multiple requests into one and caches results, reducing database load and improving performance in GraphQL resolvers.

🔧 Debug

expert

Why does this schema-first GraphQL server fail to start?

Given this schema snippet, the server throws an error on startup:

type Query {
  getUser(id: ID!): User
}

type User {
  id: ID!
  name: String!
  bestFriend: User
}

What is the most likely cause?

A The schema has a circular reference with 'User' referencing itself, which is invalid.

B There is no syntax error; the error is likely in resolver implementation.

C The schema is missing a root mutation type, causing startup failure.

D The 'bestFriend' field must be non-nullable with an exclamation mark.

💡 Hint

Think about whether self-referencing types are allowed in GraphQL schemas.

GraphQL supports self-referencing types like 'User' referencing 'User'. The schema is valid. Startup errors usually come from resolver code or server config, not this schema.

Practice

1. What is the main purpose of schema-first development in GraphQL?

easy

A. To design the data types and API structure before writing code

B. To write all the backend code before defining the API

C. To generate random queries automatically

D. To skip planning and start coding immediately

Solution

1. Step 1: Understand schema-first development

   Schema-first means you create the schema (data types and API) first before coding the backend logic.

2. Step 2: Compare options with definition

   Only To design the data types and API structure before writing code matches this idea; others describe different or incorrect approaches.

3. Final Answer:

   To design the data types and API structure before writing code -> Option A

4. Quick Check:

   Schema-first = plan schema first [OK]

Hint: Schema-first means plan schema before coding [OK]

Common Mistakes:

• Thinking schema is generated after coding
• Confusing schema-first with code-first
• Believing schema-first skips planning

2. Which of the following is the correct way to define a GraphQL type in SDL (Schema Definition Language)?

easy

A. User type { id: ID name: String }

B. type User { id: ID!, name: String! }

C. define type User { id: ID, name: String }

D. class User { id: ID; name: String; }

Solution

1. Step 1: Recall GraphQL SDL syntax

   GraphQL SDL defines types using 'type TypeName { fields }' with field types and optional ! for required.

2. Step 2: Check each option

   type User { id: ID!, name: String! } matches correct SDL syntax. The other options use incorrect keywords or syntax from other languages.

3. Final Answer:

   type User { id: ID!, name: String! } -> Option B

4. Quick Check:

   SDL type syntax = type Name { fields } [OK]

Hint: SDL uses 'type Name { fields }' syntax [OK]

Common Mistakes:

• Using 'define' keyword instead of 'type'
• Writing types like classes in other languages
• Omitting exclamation marks for required fields incorrectly

3. Given this schema snippet:

type Query { user(id: ID!): User }

and this query:

{ user(id: "1") { id name } }

What will the query return if the user with id "1" exists?

medium

A. { "data": { "user": null } }

B. { "error": "User not found" }

C. { "data": { "user": { "id": "1", "name": "Alice" } } }

D. SyntaxError

Solution

1. Step 1: Understand the schema and query

   The schema defines a Query type with a user field that takes an id and returns a User type. The query requests user with id "1" and fields id and name.

2. Step 2: Predict the output if user exists

   If user with id "1" exists, the response will include data with user object containing id and name fields.

3. Final Answer:

   { "data": { "user": { "id": "1", "name": "Alice" } } } -> Option C

4. Quick Check:

   Existing user query returns data with user object [OK]

Hint: Existing user query returns data with user object [OK]

Common Mistakes:

• Confusing null response with error
• Expecting error instead of data when user exists
• Misreading query syntax causing syntax error

4. Identify the error in this schema definition:

type Query { getUser(id: ID): User }

What is wrong here?

medium

A. ID is not a valid GraphQL type

B. The User type is missing curly braces

C. Query type cannot have arguments

D. The id argument should be non-nullable with an exclamation mark

Solution

1. Step 1: Review argument type in schema

   The argument 'id' is typed as 'ID' but lacks the exclamation mark, so it is nullable.

2. Step 2: Understand common practice for IDs

   Usually, IDs used to fetch data are required (non-nullable), so 'ID!' is preferred to ensure the argument is provided.

3. Final Answer:

   The id argument should be non-nullable with an exclamation mark -> Option D

4. Quick Check:

   Required args use ! in schema [OK]

Hint: Use ! for required arguments in schema [OK]

Common Mistakes:

• Thinking Query type cannot have arguments
• Believing User type needs braces in this line
• Assuming ID is invalid type

5. You want to add a new mutation to update a user's email in a schema-first GraphQL API. Which schema definition correctly adds this mutation?

hard

A. type Mutation { updateUserEmail(id: ID!, email: String!): User }

B. mutation updateUserEmail(id: ID!, email: String!): User

C. type Mutation updateUserEmail(id: ID!, email: String!): User

D. type Mutation { updateUserEmail(id: ID, email: String): Boolean }

Solution

1. Step 1: Recall mutation syntax in schema-first SDL

   Mutations are defined inside a 'type Mutation { ... }' block with fields representing mutation functions and their arguments and return types.

2. Step 2: Analyze each option

   type Mutation { updateUserEmail(id: ID!, email: String!): User } correctly defines a mutation field with required id and email arguments and returns a User type. mutation updateUserEmail(id: ID!, email: String!): User uses incorrect syntax without 'type'. type Mutation updateUserEmail(id: ID!, email: String!): User misses braces. type Mutation { updateUserEmail(id: ID, email: String): Boolean } uses optional args and returns Boolean, which may not match update use case.

3. Final Answer:

   type Mutation { updateUserEmail(id: ID!, email: String!): User } -> Option A

4. Quick Check:

   Mutations inside 'type Mutation { }' with args and return type [OK]

Hint: Mutations go inside 'type Mutation { }' with args and return type [OK]

Common Mistakes:

• Omitting 'type' keyword for Mutation
• Forgetting braces around Mutation fields
• Using optional args when required
• Returning wrong type for update mutation