GraphQL

Overview

GraphQL is a query language and runtime for APIs. The server publishes a typed schema, and each client sends a query describing exactly the fields it needs, possibly across related objects, in a single request. The server resolves each field with resolver functions and returns JSON in the same shape as the query.

It solves REST's over-fetching and under-fetching, which matters most for complex UIs and mobile apps. The costs are real: caching is harder (usually one POST endpoint), naive resolvers cause N+1 database queries, and clients can craft expensive queries, so production GraphQL needs batching, query cost limits, and persisted queries.

When to use it

• Many different clients need different slices of the same data.
• Screens combine data from several services in one view.
• Mobile clients on slow networks where round trips are costly.
• Rapid front-end iteration without new endpoints for every screen.

Where it shows up in interviews

Where it is used in real software

Key terms

Schema

Typed description of objects, fields, queries, and mutations.

Resolver

A function that returns the value for one field.

Mutation

An operation that changes data.

Subscription

Real-time updates pushed over WebSockets.

DataLoader

Batches and caches loads within a request to avoid N+1 queries.

How it works, step by step

1. 1
   Client sends a query

   POST /graphql with the query text (or a persisted query ID) and variables.

2. 2
   Server parses and validates

   Checks syntax and types against the schema; rejects unknown fields.

3. 3
   Cost analysis

   Estimate depth and complexity; reject queries above the limit.

4. 4
   Resolve fields

   Resolvers run for each field; DataLoader batches related lookups.

5. 5
   Return shaped JSON

   The response mirrors the query; partial errors appear in an errors array.

The N+1 problem and DataLoader

Query: 50 posts, each with its author

DataLoader is the standard fix: it waits until the current tick, collects all requested keys, and issues one batched query.

Implementation

1import DataLoader from "dataloader";2 3const typeDefs = `#graphql4  type User { id: ID!, name: String! }5  type Post { id: ID!, title: String!, author: User! }6  type Query { feed(first: Int = 20, after: String): [Post!]! }7  type Mutation { createPost(title: String!): Post! }8`;9 10// One loader per request so caching never leaks between users11function createLoaders(db: Db) {12  return {13    userById: new DataLoader<string, User>(async (ids) => {14      const rows = await db.users.findMany({ where: { id: { in: [...ids] } } });15      const byId = new Map(rows.map((u) => [u.id, u]));16      return ids.map((id) => byId.get(id)!);17    }),18  };19}20 21const resolvers = {22  Query: {23    feed: (_: unknown, args: { first: number; after?: string }, ctx: Ctx) => ctx.db.posts.page(args),24  },25  Post: {26    author: (post: Post, _: unknown, ctx: Ctx) => ctx.loaders.userById.load(post.authorId), // batched27  },28  Mutation: {29    createPost: (_: unknown, { title }: { title: string }, ctx: Ctx) => ctx.db.posts.create({ title, authorId: ctx.user.id }),30  },31};

Complexity and performance

Trade-offs

Variants and related techniques

Common mistakes

• N+1 resolver queries.

  Fix: Use DataLoader per request.

• Unbounded query depth.

  Fix: Enforce depth and complexity limits and timeouts.

• Authorization only at the endpoint.

  Fix: Check permissions in resolvers or the data layer, per field and object.

Interview questions

Practice problems