Transaction handling in GraphQL - Mini Project: Build & Apply

Transaction Handling in GraphQL

📖 Scenario: You are building a simple GraphQL API for a bookstore. Customers can place orders for books. To keep data safe, you need to handle transactions so that either the entire order is saved or nothing is saved if something goes wrong.

🎯 Goal: Build a GraphQL mutation that handles a transaction to add a new order with multiple books. The transaction should ensure all books are added to the order or none at all if an error occurs.

📋 What You'll Learn

Create a GraphQL type Order with fields id and books (list of strings).

Create a mutation createOrder that accepts a list of book titles.

Use a transaction to add the order and books atomically.

Rollback the transaction if any book title is empty.

💡 Why This Matters

🌍 Real World

Transaction handling is crucial in real-world applications like e-commerce to keep data consistent and avoid partial updates.

💼 Career

Understanding how to implement transactions in GraphQL APIs is important for backend developers working with databases and APIs.

1

Define the Order type

Create a GraphQL type called Order with fields id of type ID! and books which is a list of non-nullable String!.

GraphQL

# Define the Order type here

Hint

Use type Order { id: ID! books: [String!]! } syntax.

2

Add createOrder mutation signature

Add a mutation called createOrder that takes an argument bookTitles which is a list of non-nullable String! and returns an Order.

GraphQL

type Order {
  id: ID!
  books: [String!]!
}

# Add createOrder mutation signature here

Hint

Mutations are defined inside type Mutation { ... }.

3

Implement transaction logic in resolver

In the resolver for createOrder, start a transaction, check that no book title is empty, add the order with books, and commit the transaction. If any book title is empty, rollback the transaction.

GraphQL

type Order {
  id: ID!
  books: [String!]!
}

type Mutation {
  createOrder(bookTitles: [String!]!): Order
}

const resolvers = {
  Mutation: {
    createOrder: async (_, { bookTitles }, { db }) => {
      // Start transaction
      // Check for empty titles
      // Add order and books
      // Commit or rollback
    }
  }
};

Hint

Use try...catch with transaction.commit() and transaction.rollback().

4

Complete the GraphQL schema export

Export the GraphQL schema including the Order type and Mutation type with createOrder mutation.

GraphQL

type Order {
  id: ID!
  books: [String!]!
}

type Mutation {
  createOrder(bookTitles: [String!]!): Order
}

const resolvers = {
  Mutation: {
    createOrder: async (_, { bookTitles }, { db }) => {
      const transaction = await db.transaction();
      try {
        if (bookTitles.some(title => title === "")) {
          throw new Error("Book title cannot be empty");
        }
        const order = await db.orders.create({ books: bookTitles }, { transaction });
        await transaction.commit();
        return order;
      } catch (error) {
        await transaction.rollback();
        throw error;
      }
    }
  }
};

# Export schema here

Hint

Export typeDefs and resolvers for your GraphQL server.

Practice

1. What is the main purpose of using transactions in a database when working with GraphQL?

easy

A. To group multiple actions so they all succeed or fail together

B. To speed up query execution by caching results

C. To automatically generate GraphQL schemas

D. To encrypt data sent over the network

Solution

1. Step 1: Understand what transactions do

   Transactions ensure that a set of database operations are treated as a single unit.

2. Step 2: Identify the purpose in GraphQL context

   This means either all changes succeed or none do, keeping data consistent.

3. Final Answer:

   To group multiple actions so they all succeed or fail together -> Option A

4. Quick Check:

   Transactions = atomic group actions [OK]

Hint: Transactions keep multiple changes safe together [OK]

Common Mistakes:

• Thinking transactions speed up queries
• Confusing transactions with schema generation
• Assuming transactions encrypt data

2. Which of the following is the correct way to start a transaction in a GraphQL resolver using a typical backend?

easy

A. const transaction = await db.rollback();

B. const transaction = db.commit();

C. const transaction = await db.startTransaction();

D. const transaction = db.query('BEGIN');

Solution

1. Step 1: Identify how to start a transaction

   Starting a transaction usually involves calling a method like startTransaction() asynchronously.

2. Step 2: Check options for correctness

   const transaction = await db.startTransaction(); correctly uses await and startTransaction(), while others are commit, rollback, or raw query.

3. Final Answer:

   const transaction = await db.startTransaction(); -> Option C

4. Quick Check:

   Start transaction = startTransaction() [OK]

Hint: Start transactions with async startTransaction() method [OK]

Common Mistakes:

• Using commit or rollback to start a transaction
• Using raw query strings instead of methods
• Missing await for async calls

3. Given this GraphQL resolver snippet, what will be the output if an error occurs during updateUser()?

async function updateProfile(parent, args, context) {
  const trx = await context.db.startTransaction();
  try {
    await trx.updateUser(args.userId, args.data);
    await trx.commit();
    return 'Success';
  } catch (e) {
    await trx.rollback();
    return 'Failed';
  }
}

medium

A. 'Success'

B. 'Failed'

C. Throws an unhandled exception

D. Returns null

Solution

1. Step 1: Analyze the try block

   The code tries to update the user and commit the transaction.

2. Step 2: Understand error handling

   If updateUser throws an error, the catch block rolls back and returns 'Failed'.

3. Final Answer:

   'Failed' -> Option B

4. Quick Check:

   Error during update = rollback + 'Failed' [OK]

Hint: Errors trigger rollback and return 'Failed' [OK]

Common Mistakes:

• Assuming commit runs even on error
• Expecting unhandled exceptions instead of catch
• Thinking it returns 'Success' always

4. Identify the error in this GraphQL resolver transaction handling code:

async function saveOrder(parent, args, context) {
  const trx = context.db.startTransaction();
  try {
    await trx.insertOrder(args.order);
    await trx.commit();
    return 'Order saved';
  } catch (error) {
    await trx.rollback();
    return 'Error saving order';
  }
}

medium

A. Missing await before startTransaction()

B. No rollback in catch block

C. commit() should be called before insertOrder()

D. Returning string instead of object

Solution

1. Step 1: Check transaction start syntax

   startTransaction() is asynchronous and must be awaited.

2. Step 2: Identify missing await impact

   Without await, trx is a Promise, causing errors on trx.insertOrder().

3. Final Answer:

   Missing await before startTransaction() -> Option A

4. Quick Check:

   Async startTransaction() needs await [OK]

Hint: Always await async transaction start calls [OK]

Common Mistakes:

• Forgetting await on async calls
• Calling commit before operations
• Ignoring rollback on errors

5. You want to update a user's profile and their related settings in one transaction using GraphQL. Which approach ensures both updates succeed or fail together?

async function updateUserAndSettings(parent, args, context) {
  const trx = await context.db.startTransaction();
  try {
    await trx.updateUser(args.userId, args.userData);
    await trx.updateSettings(args.userId, args.settingsData);
    await trx.commit();
    return 'Update successful';
  } catch (error) {
    await trx.rollback();
    return 'Update failed';
  }
}

hard

A. Use separate transactions for user and settings updates

B. Do not use transactions for related updates

C. Commit after each update separately

D. Wrap both updates in a single transaction as shown

Solution

1. Step 1: Understand transaction grouping

   Both updates must be inside one transaction to succeed or fail together.

2. Step 2: Analyze the code approach

   The code wraps both updates in one transaction, committing only if both succeed.

3. Final Answer:

   Wrap both updates in a single transaction as shown -> Option D

4. Quick Check:

   Single transaction = atomic multi-update [OK]

Hint: Group related updates in one transaction [OK]

Common Mistakes:

• Using separate transactions causing partial updates
• Committing too early after first update
• Skipping transactions for multi-step changes