Circular Queries and Cycle Guards

Where the Loop Actually Comes From

Cyclic schemas are ordinary: users follow users, comments reply to comments, categories contain categories. The danger is that a cyclic type plus an eager client equals unbounded work.

type User {
  id: ID!
  name: String!
  friends: [User!]!     # self-referencing edge
}

The tempting shortcut — a fragment that expands itself — is rejected before execution:

query Recurse {
  user(id: "1") { ...Friend }
}

fragment Friend on User {
  name
  friends { ...Friend }
}

Fragment "Friend" cannot be spread here as it would create a cycle.

So a query never loops syntactically: documents are finite and fragment cycles fail validation. The three ways a schema cycle turns into a real cost:

1. Hand-expanded depth. The client spells out eight levels literally. The document is valid, and execution walks every level.
2. Fan-out multiplication. Each level multiplies: friends with 200 per user reaches 40,000 at depth 3, 8,000,000 at depth 4, and 1.6 billion at depth 5.
3. Resolver-side traversal. A resolver that eagerly walks both edges of a cycle in memory loops regardless of what the document says — the document asked for one field, the resolver did the walking.

The first two are client-shaped risks stopped by validation-time controls; the third is server code and needs its own guard. The next two chapters handle them in that order.

Fan-out arithmetic for friends at 200 per user, one document, no cycle:

Four lines of query, eight million resolver calls — and writing it out explicitly is the only way to get there once fragment cycles are off the table.

Stop the Recursion Before Execution

Depth limiting rejects over-deep documents while the request is still being validated:

import depthLimit from 'graphql-depth-limit';

const apolloServer = new ApolloServer({
  schema,
  validationRules: [depthLimit(7)],
});

Validation error: query exceeds maximum depth 7 (found 9)

Placement matters: as a validation rule the rejection happens before a single resolver runs, so a hostile query costs one parse. Guarding inside resolvers is too late — the traversal already started.

Depth alone is blunt. It charges the same for posts { id } and posts { comments { authors { … } } } at each level even though one reads rows and the other multiplies them. Cost analysis weights fields instead:

level 1  posts      cost 1
level 2  comments   cost × 20    → 20
level 3  authors    cost × 1     → 20
level 4  friends    cost × 50    → 1000 per starting post

// budget style: each field declares a base cost and a list multiplier
const costs = { posts: 1, comments: 20, authors: 1, friends: 50 };
const total = priceQuery(document, costs);   // reject if total > budget

Use both: a hard depth limit as the cheap backstop that catches pathological shapes, and a cost budget as the precise control that prices fan-out. See query depth limits and cost analysis and budgets for the tradeoffs of each.

One nuance interviewers like: because validation checks the document as written, a field hidden behind @skip(if: true) still counts toward depth — the validator does not evaluate variables. Budgeting cannot read the client's intent either, which is why the budget is conservative.

Resolvers That Walk the Graph Safely

When the server itself traverses relations — building a comment thread, expanding a follower graph, materializing an org chart — document-level limits do not help, because the document looks innocent. Bound the walk in code:

function buildThread(comment, depth = 0, seen = new Set()) {
  if (depth > 5 || seen.has(comment.id)) return null;   // depth cap + visited set
  const next = new Set(seen);
  next.add(comment.id);
  return {
    ...comment,
    replies: comment.replyIds.map((id) =>
      buildThread(loadComment(id), depth + 1, next)),
  };
}

You need both guards, because they stop different shapes of runaway:

Breadth-first with a queue and an explicit maxNodes budget is the same idea with a hard cap on total work — useful when depth is shallow but fan-out is extreme.

Schema review rules that catch this before it ships:

• Every self-referencing list field takes a limiting argument or returns a paginated connection.
• Eager in-memory expansion of relations is the N+1 pattern wearing a different hat — batch the lookups (see the N+1 pattern).
• Flag any recursive path where every edge is a non-null list: those are the fields clients will abuse first.

Interview framing, in this order: fragment cycles are a validation error, type cycles are legal, the runtime risk is fan-out plus resolver traversal, then name the three controls — depth limit, cost budget, visited set.

A cheap review heuristic to close on: list every self-referencing list field in the schema, then check each one for a limiting argument or a connection. Those lines are where a hostile query starts, and they are the only ones that need a second look.