Server middleware in GraphQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ query_result

intermediate

Middleware effect on query response

Consider a GraphQL server with middleware that adds a requestId field to the context for each request. Given the query below, what will be the output if the middleware correctly adds a unique requestId?

query GetUser {
  user(id: "1") {
    id
    name
    requestId
  }
}

Assume the user with id "1" has name "Alice".

A {"data": {"user": {"id": "1", "name": "Alice", "requestId": "req-123"}}}

B {"data": {"user": null}}

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

D {"errors": [{"message": "Field \"requestId\" not found on type User"}]}

💡 Hint

Think about the GraphQL schema and what fields are defined on the User type.

The requestId is added to the context by middleware but is not part of the User type in the schema. Therefore, querying requestId on user causes a schema validation error.

🧠 Conceptual

intermediate

Purpose of server middleware in GraphQL

What is the primary purpose of server middleware in a GraphQL server?

A To modify the GraphQL schema dynamically during query execution

B To intercept and process requests before they reach the resolver functions

C To generate client-side queries automatically

D To store data permanently in the database

💡 Hint

Think about what middleware usually does in web servers.

Middleware acts as a layer that can inspect, modify, or reject requests before they reach the GraphQL resolvers. It is not responsible for schema changes, client query generation, or data storage.

📝 Syntax

advanced

Identify the syntax error in middleware setup

Which option contains a syntax error in setting up Express middleware for a GraphQL server?

GraphQL

const express = require('express');
const { graphqlHTTP } = require('express-graphql');
const app = express();

app.use('/graphql', (req, res, next) => {
  req.context = { user: 'admin' };
  next();
});

app.use('/graphql', graphqlHTTP({
  schema: mySchema,
  graphiql: true,
  context: req.context
}));

A The middleware function does not call next(), causing requests to hang

B The app.use calls should be combined into one call

C The context option in graphqlHTTP cannot access req.context directly like this

D The schema variable mySchema is not imported

💡 Hint

Consider how the context option is set in express-graphql.

The context option in graphqlHTTP must be a function or an object. Here, req.context is undefined at the time of middleware setup because req is not accessible outside the middleware function. The correct approach is to pass a function that receives req and returns the context.

🔧 Debug

advanced

Debugging middleware order issue

A developer notices that authentication middleware is not working as expected in their GraphQL server. The middleware is supposed to add a user object to the context, but resolvers receive undefined. What is the most likely cause?

GraphQL

app.use('/graphql', graphqlHTTP({
  schema: mySchema,
  graphiql: true,
  context: ({ req }) => req.user
}));

app.use('/graphql', (req, res, next) => {
  req.user = { id: '123', name: 'Alice' };
  next();
});

A The authentication middleware is registered after the graphqlHTTP middleware, so it runs too late

B The context function is not returning the user object correctly

C The schema does not define a user type

D The middleware does not call next()

💡 Hint

Think about the order in which middleware functions are executed in Express.

Express executes middleware in the order they are registered. Since the authentication middleware is registered after the GraphQL middleware, the req.user is not set when the context function runs, resulting in undefined.

❓ optimization

expert

Optimizing middleware for performance

In a high-traffic GraphQL server, which middleware optimization will most effectively reduce latency?

A Cache authentication results in middleware to avoid repeated checks per request

B Move authentication checks into resolvers instead of middleware

C Remove all middleware and handle everything in resolvers

D Use synchronous middleware functions to simplify code

💡 Hint

Consider how caching can reduce repeated work in middleware.

Caching authentication results in middleware avoids repeated expensive checks for the same user during a request or across requests, reducing latency. Moving checks into resolvers or removing middleware increases complexity and latency. Synchronous middleware can block the event loop, hurting performance.

Practice

1. What is the main purpose of server middleware in a GraphQL server?

easy

A. To run code before GraphQL resolvers to manage requests

B. To define the GraphQL schema types

C. To execute database queries directly

D. To format the GraphQL query results

Solution

1. Step 1: Understand middleware role

   Middleware runs before the main GraphQL code to handle requests.

2. Step 2: Identify middleware tasks

   It can check, log, or modify requests before resolvers run.

3. Final Answer:

   To run code before GraphQL resolvers to manage requests -> Option A

4. Quick Check:

   Middleware manages requests before resolvers [OK]

Hint: Middleware runs before resolvers to manage requests [OK]

Common Mistakes:

• Confusing middleware with schema definition
• Thinking middleware executes database queries
• Assuming middleware formats results

2. Which of the following is the correct way to call the next middleware function in a GraphQL server middleware?

easy

A. next();

B. continue();

C. proceed();

D. runNext();

Solution

1. Step 1: Recall middleware function signature

   Middleware functions receive a next callback to continue processing.

2. Step 2: Identify correct call syntax

   The standard call to continue is next(); exactly.

3. Final Answer:

   next(); -> Option A

4. Quick Check:

   Use next() to continue middleware chain [OK]

Hint: Call next() to continue middleware processing [OK]

Common Mistakes:

• Using incorrect function names like continue()
• Forgetting to call next() causing request hang
• Calling next without parentheses

3. Given this middleware code snippet, what will be logged when a request is made?

function logMiddleware(req, res, next) {
  console.log('Request received');
  next();
  console.log('Request processed');
}

medium

A. Request processed\nRequest received

B. Request received\nRequest processed

C. Only Request received

D. Only Request processed

Solution

1. Step 1: Analyze middleware execution order

   First, 'Request received' logs before calling next().

2. Step 2: Understand next() behavior

   After next() completes, 'Request processed' logs.

3. Final Answer:

   Request received\nRequest processed -> Option B

4. Quick Check:

   Logs before and after next() run in order [OK]

Hint: Logs before and after next() run in order [OK]

Common Mistakes:

• Assuming next() blocks logging after it
• Thinking logs reverse order
• Ignoring that next() allows later code to run

4. Identify the error in this middleware code:

function authMiddleware(req, res, next) {
  if (!req.user) {
    res.status(401).send('Unauthorized');
  }
  next();
}

medium

A. req.user check should be after next()

B. Missing call to next() inside if block

C. res.status should be res.sendStatus

D. next() is called even after sending response

Solution

1. Step 1: Check flow after sending response

   If !req.user, response is sent but next() still runs.

2. Step 2: Understand middleware flow control

   Calling next() after sending response can cause errors or duplicate handling.

3. Final Answer:

   next() is called even after sending response -> Option D

4. Quick Check:

   Stop calling next() after response sent [OK]

Hint: Don't call next() after sending response [OK]

Common Mistakes:

• Calling next() unconditionally after response
• Not returning after sending response
• Misplacing user check after next()

5. You want to add middleware that logs the request time and then modifies the request object to add a requestId before GraphQL resolvers run. Which middleware code correctly achieves this?

hard

A. function middleware(req, res, next) {
req.requestTime = Date.now();
next();
res.requestId = Math.random().toString(36).slice(2);
}

B. function middleware(req, res) {
req.requestTime = Date.now();
next();
req.requestId = Math.random().toString(36).slice(2);
}

C. function middleware(req, res, next) {
req.requestTime = Date.now();
req.requestId = Math.random().toString(36).slice(2);
next();
}

D. function middleware(req, res, next) {
next();
req.requestTime = Date.now();
req.requestId = Math.random().toString(36).slice(2);
}

Solution

1. Step 1: Ensure middleware modifies request before next()

   Properties must be set on req before calling next() to be available in resolvers.

2. Step 2: Check correct use of next() and property assignment

   function middleware(req, res, next) { req.requestTime = Date.now(); req.requestId = Math.random().toString(36).slice(2); next(); } sets both properties before next(), ensuring proper order and correct object.

3. Final Answer:

   function middleware(req, res, next) { req.requestTime = Date.now(); req.requestId = Math.random().toString(36).slice(2); next(); } -> Option C

4. Quick Check:

   Set req properties before next() call [OK]

Hint: Set req properties before next() to pass data [OK]

Common Mistakes:

• Calling next() before setting properties
• Modifying res instead of req for request data
• Missing next() parameter or call