GraphQL

GraphQL is schema-driven, not resource-URL-driven

GraphQL is a query language and runtime for APIs. Clients send a structured query describing exactly which fields they need. It is not REST — there is usually one HTTP endpoint (often POST /graphql), and read/write shapes come from a schema, not from many resource URLs.

GraphQL shines when multiple clients need different views of the same graph (web dashboard vs mobile vs partner API) without proliferating REST endpoints.

Core ideas

Schema-first

The server exposes a typed schema: objects, fields, arguments, enums, interfaces, unions. Tools validate queries at dev time and generate client types (codegen). The schema is the contract — analogous to OpenAPI for REST or .proto for gRPC.

Example query (conceptual):

query {
  user(id: "1") {
    name
    email
    orders(first: 10) {
      edges {
        node {
          id
          total
        }
      }
    }
  }
}

One round trip returns the nested tree the client asked for.

Queries, mutations, subscriptions

• Query — read data; shaped as a tree of fields. Should not mutate server state (discipline enforced by convention and review).
• Mutation — change data; returns fields you request (often including affected objects and error payloads).
• Subscription — push updates, commonly over WebSockets; implementation varies by server (Absinthe, Apollo, etc.).

One endpoint, many shapes

Instead of:

GET /users/1
GET /users/1/orders
GET /users/1/orders/42/line-items

the client sends one query nesting user → orders → lineItems with only the fields needed for that screen.

Strengths

• Reduced over-fetching — mobile clients skip heavy fields the web app needs.
• Product velocity — new UI views compose existing schema fields without waiting for N new REST endpoints (if the graph already exposes the data).
• Strong tooling — introspection in dev, GraphiQL, codegen, query validation.
• Single request for graphs — fewer waterfall round trips compared to naive REST client chaining.

Challenges interviewers probe

N+1 resolver problem

Naive implementation: fetch user, then for each order run another database query → 1 + N queries.

Mitigations:

• Batching — DataLoader pattern: collect ids during a tick, one WHERE id IN (...) query.
• Joins at the database — resolve nested fields with a single SQL query or ORM eager load.
• Lookahead / query planning — inspect the GraphQL AST and prefetch relationships.

Name N+1 unprompted when discussing GraphQL trade-offs; it separates candidates who shipped it from those who read a blog post.

Caching vs REST

HTTP caching of GET by URL is straightforward and CDN-friendly. GraphQL often uses POST with a JSON body — browsers and CDNs do not cache that by default.

Mitigations:

• Client-side caches (Apollo, Relay normalized stores)
• Persisted queries — server maps query id → text; GET with hash in URL for cacheable reads
• CDN configuration for allowlisted persisted queries
• Server-side response caching keyed by query + variables (TTL, invalidation discipline)

Complexity limits

Deeply nested queries can DOS the server (user { friends { friends { friends { ... }}}}).

Production APIs use:

• Depth limits
• Cost analysis / query complexity scoring
• Timeouts per request
• Pagination on lists — Relay connections pattern (edges, node, pageInfo, cursors)

Authorization

Every field may need a permission check. REST often centralizes auth once per route; GraphQL needs discipline per resolver or field-level middleware, or you leak data through nested fields.

Model auth early: “Can this viewer see this user’s email?” on the email field, not only on Query.user.

Federation (at scale)

Large orgs split the graph across services — Apollo Federation, GraphQL Mesh, etc. — while exposing one conceptual schema to clients. Each team owns subgraph types; a gateway stitches them. Mention when discussing enterprise adoption; skip unless the interviewer asks about multi-team graphs.

GraphQL vs REST (when this chapter is not enough)

GraphQL is not “REST but better.” It trades URL cacheability and simple HTTP semantics for client-driven shape. See REST vs RPC vs GraphQL for the full decision matrix.

Interview framing

“Is GraphQL REST?” — No. Different style: one endpoint, client-specified field tree, schema contract. You can host it over HTTP with disciplined status codes, but it does not use many resource URLs the REST way.

“What is the N+1 problem?” — Resolvers fetching related entities one row at a time; fix with batching (DataLoader), joins, or query planning.

“How do you cache GraphQL?” — Client normalized cache, persisted queries, server-side keyed cache — not default CDN GET caching like REST.

Next: REST vs RPC vs GraphQL — pick by constraints, not hype.