Error handling on client in GraphQL - Mini Project: Build & Apply

Error Handling on Client with GraphQL

📖 Scenario: You are building a simple client application that fetches user data from a GraphQL API. Sometimes, the API might return errors, such as when a user ID does not exist. You want to handle these errors gracefully on the client side.

🎯 Goal: Build a GraphQL query and client-side error handling logic that fetches user information and properly handles any errors returned by the server.

📋 What You'll Learn

Create a GraphQL query named GET_USER that fetches id, name, and email for a user by id.

Define a variable userId to specify which user to fetch.

Write a client function fetchUser that executes the GET_USER query with userId and handles errors.

Add error handling logic that checks if the response contains errors and stores them in a variable errorMessage.

💡 Why This Matters

🌍 Real World

Client applications often need to fetch data from GraphQL APIs and handle errors gracefully to improve user experience.

💼 Career

Understanding how to query GraphQL APIs and handle errors is essential for frontend and full-stack developers working with modern APIs.

1

Create the GraphQL query

Create a GraphQL query called GET_USER that takes a variable $id of type ID! and fetches the fields id, name, and email of the user with that id.

GraphQL

# Write the GraphQL query GET_USER here
# Your code here

Hint

Use the query keyword, define a variable $id of type ID!, and request the user field with that id.

2

Define the userId variable

Define a variable called userId and set it to the string "123" to specify the user ID you want to fetch.

GraphQL

GET_USER = """query GET_USER($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}
"""

# Define userId variable here
# Your code here

Hint

Assign the string "123" to the variable userId.

3

Write the fetchUser function

Write a function called fetchUser that takes no arguments and calls a generic graphqlClient.query method with the GET_USER query and variables containing id: userId. Store the result in a variable called response.

GraphQL

GET_USER = """query GET_USER($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}
"""

userId = "123"

# Write fetchUser function here
# Your code here

Hint

Define a function fetchUser and call graphqlClient.query with the query and variables.

4

Add error handling logic

Inside the fetchUser function, add code to check if response contains an errors field. If it does, set a variable errorMessage to the first error message string. Otherwise, set errorMessage to None.

GraphQL

GET_USER = """query GET_USER($id: ID!) {
  user(id: $id) {
    id
    name
    email
  }
}
"""

userId = "123"

def fetchUser():
    response = graphqlClient.query(GET_USER, variables={"id": userId})
    # Add error handling here
    # Your code here

Hint

Use an if statement to check for errors in the response and assign errorMessage accordingly.

Practice

1. What is the main purpose of error handling on the client side in GraphQL applications?

easy

A. To speed up the server response time

B. To keep the app stable and show clear messages to users

C. To change the GraphQL schema dynamically

D. To store data permanently on the client

Solution

1. Step 1: Understand client-side error handling

   Error handling on the client is about managing problems that happen when fetching or processing data, so the app doesn't crash.

2. Step 2: Identify the main goal

   The goal is to keep the app stable and inform users clearly about what went wrong.

3. Final Answer:

   To keep the app stable and show clear messages to users -> Option B

4. Quick Check:

   Error handling = stability + clear messages [OK]

Hint: Error handling means stability and clear user messages [OK]

Common Mistakes:

• Thinking error handling speeds up server
• Confusing error handling with schema changes
• Assuming error handling stores data

2. Which of the following is the correct way to catch errors from a GraphQL query using promises on the client?

easy

A. client.query(...).then(...).catch(error => handleError(error))

B. client.query(...).catch(...).then(error => handleError(error))

C. client.query(...).try(error => handleError(error))

D. client.query(...).error(error => handleError(error))

Solution

1. Step 1: Recall promise error handling syntax

   Promises use .then() for success and .catch() for errors.

2. Step 2: Match correct chaining

   The correct order is .then(...).catch(...). client.query(...).then(...).catch(error => handleError(error)) matches this.

3. Final Answer:

   client.query(...).then(...).catch(error => handleError(error)) -> Option A

4. Quick Check:

   Promise catch method = .catch() [OK]

Hint: Use .then() before .catch() to handle errors [OK]

Common Mistakes:

• Placing .catch() before .then()
• Using non-existent .try() or .error() methods
• Ignoring promise chaining order

3. Given the following code snippet, what will be logged if the GraphQL query fails?

client.query({ query: GET_USER })
  .then(response => console.log('User:', response.data.user))
  .catch(error => console.log('Error:', error.message))

medium

A. User: undefined

B. No output

C. User: null

D. Error: [error message from server]

Solution

1. Step 1: Understand promise flow on failure

   If the query fails, the .catch() block runs, logging the error message.

2. Step 2: Identify logged output

   The console logs 'Error:' followed by the error message from the server.

3. Final Answer:

   Error: [error message from server] -> Option D

4. Quick Check:

   Failed query triggers .catch() logging error [OK]

Hint: Failed queries run .catch() logging error message [OK]

Common Mistakes:

• Assuming .then() runs on failure
• Expecting 'User: undefined' instead of error
• Thinking no output appears on error

4. Identify the error in this client-side GraphQL error handling code:

try {
  const response = await client.query({ query: GET_POSTS });
  console.log(response.data.posts);
} catch {
  console.log('Failed to fetch posts');
}

medium

A. client.query does not return a promise

B. Using await inside try block is invalid

C. Missing error parameter in catch block

D. console.log cannot be used inside catch

Solution

1. Step 1: Review try-catch syntax

   The catch block should include an error parameter to access error details.

2. Step 2: Identify missing error parameter

   The code uses catch { ... } without (error), preventing access to the error details.

3. Final Answer:

   Missing error parameter in catch block -> Option C

4. Quick Check:

   catch needs (error) parameter [OK]

Hint: Always include error parameter in catch block [OK]

Common Mistakes:

• Omitting error parameter in catch
• Thinking await is invalid in try
• Believing client.query is not a promise

5. You want to show a friendly message to users when a GraphQL mutation fails due to network issues. Which approach correctly handles this on the client?

async function submitData() {
  try {
    const result = await client.mutate({ mutation: ADD_ITEM, variables: { name: 'Book' } });
    console.log('Item added:', result.data.addItem.id);
  } catch (error) {
    if (error.networkError) {
      alert('Network problem, please try again later.');
    } else {
      alert('An error occurred.');
    }
  }
}

hard

A. This code correctly distinguishes network errors and shows messages

B. The catch block should not check error properties

C. Using alert is not allowed in error handling

D. await cannot be used with client.mutate

Solution

1. Step 1: Analyze error handling logic

   The catch block checks if the error is a network error and shows a specific message.

2. Step 2: Confirm correct usage of await and alerts

   Using await with client.mutate is valid, and alerts are acceptable for user messages.

3. Final Answer:

   This code correctly distinguishes network errors and shows messages -> Option A

4. Quick Check:

   Check error.networkError to show friendly messages [OK]

Hint: Check error.networkError to show specific messages [OK]

Common Mistakes:

• Ignoring networkError property in catch
• Thinking alerts are disallowed
• Misunderstanding await usage with mutate