Bird
Raised Fist0
GraphQLquery~5 mins

Server middleware in GraphQL - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: Server middleware
O(n)
Understanding Time Complexity

When using server middleware in GraphQL, it is important to understand how the time it takes to handle requests grows as more requests or data come in.

We want to know how the processing time changes when middleware runs before the main query logic.

Scenario Under Consideration

Analyze the time complexity of the following GraphQL middleware setup.


const middleware = async (resolve, root, args, context, info) => {
  // Example: logging each request
  console.log('Request received');
  const result = await resolve(root, args, context, info);
  return result;
};

const resolvers = {
  Query: {
    user: middleware(async (root, args, context, info) => {
      // fetch user by id
      return getUserById(args.id);
    })
  }
};
    

This code adds middleware that runs before the main resolver to log requests, then calls the resolver to fetch data.

Identify Repeating Operations

Look for repeated actions that affect time.

  • Primary operation: Middleware runs once per GraphQL query request.
  • How many times: Once for each query execution, before the resolver runs.
How Execution Grows With Input

As the number of queries increases, the middleware runs once per query.

Input Size (number of queries)Approx. Operations
1010 middleware calls
100100 middleware calls
10001000 middleware calls

Pattern observation: The total work grows directly with the number of queries, adding a small fixed cost each time.

Final Time Complexity

Time Complexity: O(n)

This means the middleware adds a small, constant amount of work for each query, so total time grows linearly with the number of queries.

Common Mistake

[X] Wrong: "Middleware runs once and handles all queries together, so time does not grow with more queries."

[OK] Correct: Middleware runs separately for each query request, so more queries mean more middleware executions.

Interview Connect

Understanding how middleware affects time helps you design efficient GraphQL servers and shows you can think about performance in real applications.

Self-Check

What if the middleware made a database call before each resolver? How would that change the time complexity?

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard