GraphQL — Schema Design, N+1, Federation & When Not to Use It

Overview

Interviewers care less about "one endpoint" and more about when the graph is the wrong tool, how nullability breaks clients, and whether you can stop a query from melting a database.

Prefer GraphQL when several product clients need different nested shapes and a team can staff schema review, resolver performance, and abuse controls.

Prefer REST for cacheable public reads, simple partner CRUD, file upload, and bulk export. Path and versioning depth stays in API Design. Page tokens stay in pagination.

Prefer gRPC inside the mesh. Streaming and wire compatibility stay in gRPC and Protobuf. The decision matrix that already exists is gRPC versus REST and GraphQL. Do not rebuild it here.

Why the graph exists

REST makes the server pick the JSON shape. A mobile order screen then either downloads unused fields or makes a second call per line. GraphQL lets the client name the subtree. That power moves work onto the server: every selected field is a function call, and a list multiplies those calls.

Senior loops come back to five questions:

1. Can the schema grow without breaking old clients?
2. Do you see N+1 before production does?
3. What stops a malicious selection set?
4. When is a gateway worth the operational tax?
5. When should you refuse GraphQL?

GraphQL versus REST versus gRPC

Rule of thumb: GraphQL shines as a product aggregation layer. It is a poor file pipe and a poor CDN.

flowchart TB
  a["Product clients?"]
  b["gRPC or internal REST"]
  c["Different shapes?"]
  d["REST plus versioning"]
  a -->|No| b
  a -->|Yes| c
  c -->|No| d

Single column. Each decision has two exits. No subgraph.

When not to use GraphQL

1. Bulk download or an analytics extract. The client wants pages of rows. A selection set adds overhead and no product value.
2. CDN-first media. A REST GET with cache headers wins. A GraphQL POST misses a naive CDN.
3. Ultra-simple public CRUD. One resource and a few fields. Partners read REST more easily.
4. File upload pipelines. Multipart REST or a signed URL is simpler than GraphQL upload quirks.
5. Mesh-scale fan-out. gRPC streams or a dedicated bus. GraphQL subscriptions fit a product UI, not every telemetry pipe. Realtime protocol choice: WebSockets and MQTT.
6. No schema owners. An ungoverned graph becomes one unmaintainable mega-endpoint.

Cluster map

Schema is the product contract

Treat the schema like a public API:

• Prefer non-null only when the business guarantees the value for the life of the field.
• Use input types on mutations. Do not hide writes on the query type.
• Ship additive fields first. Deprecate, then delete.
• Teach clients that errors can arrive next to partial data.

Depth: Schema design.

type Query {
  viewer: User
  order(id: ID!): Order
}

type User {
  id: ID!
  email: String
  orders(first: Int = 20): [Order!]!
}

type Order {
  id: ID!
  status: OrderStatus!
  lines: [OrderLine!]!
}

enum OrderStatus {
  PENDING
  PAID
  SHIPPED
  CANCELLED
}

type Mutation {
  placeOrder(input: PlaceOrderInput!): PlaceOrderPayload!
}

input PlaceOrderInput {
  sku: String!
  qty: Int!
  idempotencyKey: String!
}

viewer stays nullable so anonymous traffic is honest. order may be null when the id is missing. List items are non-null only when a row cannot be a hole. The idempotency key is a hook into idempotency keys, not a second lesson on dedupe storage.

Resolvers and N+1, in one pass

A naive child resolver runs once per parent row. Fix it with a batch function and a cache that live for one request. Measure field latency and query counts, not only the HTTP timer.

Depth: Resolvers and N+1.

AuthZ, cost, and federation, as pointers

• Authenticate at the edge. Authorize in the field or the loader. A root check does not cover nested email or notes.
• Put a depth limit and a cost score on public graphs. Persisted queries for first-party apps.
• A monolith schema is enough until domain teams are real. A gateway is a platform product with its own SLO.

Depth: AuthZ and abuse protection and federation.

Pros and cons

Pros

• Fewer round trips for nested product screens.
• Tooling from a typed schema and introspection.
• One BFF can sit over many REST or gRPC leaves.

Cons

• CDN and HTTP cache semantics are worse than GET.
• N+1 and abusive queries are the default without discipline.
• The AuthZ surface grows with every field.
• Upload, bulk export, and tiny partner APIs are often worse DX.

Sandbox: a tiny cost score

Real servers walk the AST. This sketch only shows the interview idea: list fields cost more than scalar fields, and a multiplier stands in for first.

Press Run. Snippets must be self-contained — no network, files, or native modules.

Sandbox: batch keys once

Press Run. Snippets must be self-contained — no network, files, or native modules.

Pitfalls

Interview Q&A

Go Deeper

• GraphQL Learn
• GraphQL Best Practices
• Apollo GraphQL Blog
• GraphQL: The Documentary
• Next: Schema Design — Types, Nullability, Inputs and Evolution