GraphQL Advanced

The language used to define a GraphQL schema — describes types, fields, queries, mutations, and subscriptions. Schema-first design means frontend and backend can agree on the contract before implementation.

"Before writing any resolver logic, we define the schema in SDL — frontend can start mocking immediately while backend implements."

A function that populates the data for a single field in the GraphQL schema. Receives four arguments: parent (parent resolver result), args (field arguments), context (shared request context), info (execution metadata).

"The posts field on User has its own resolver — it receives the user object as the parent and fetches posts for that specific user."

The execution order of resolvers for a query — the root resolver runs first, then each child field's resolver runs in turn, receiving its parent's result as the first argument.

"In the resolver chain, the User resolver runs first, then the posts resolver for each user, then the title resolver for each post."

A read operation in GraphQL — retrieving data. The GraphQL equivalent of HTTP GET. Clients declare exactly what data they need; the server returns only that.

"The query specifies exactly which user fields and nested post fields to return — no over-fetching, no under-fetching."

A write operation in GraphQL — creating, updating, or deleting data. Best practice: always return the modified entity so the client can update its cache without a separate query.

"We always return the updated user from our mutations so Apollo Client can automatically update the cache."

A real-time GraphQL operation — the client subscribes to a data stream and receives updates when the data changes. Typically implemented over WebSockets.

"The chat feature uses a subscription — clients receive new messages in real time as soon as they are posted."

A reusable unit of fields in GraphQL that can be embedded in multiple operations. Reduces repetition and allows components to declare their data dependencies independently.

"Each React component declares a UserFields fragment — the parent query spreads all component fragments together."

A GraphQL (and ORM) performance issue: fetching N items and loading a related field for each with a separate query results in N+1 total queries. For 100 users with posts: 1 query for users + 100 queries for posts = 101 queries.

"Before DataLoader, fetching 100 users with their posts made 101 database queries. The N+1 problem was crushing our DB."

A utility library that solves the N+1 problem by batching and caching requests. Collects all IDs requested in a single tick and runs one batched query. Also provides per-request caching.

"After DataLoader, fetching 100 users with their posts makes 2 queries — one for users, one for all their posts combined."

An architecture for composing a single, unified GraphQL schema from multiple independent subgraph services. Each team owns a subgraph; a gateway stitches them into a supergraph.

"Each team owns their GraphQL subgraph — the user team owns user types, the product team owns product types. Our gateway federates them into one API."

In Apollo Federation: a supergraph is the complete unified schema (what clients query); a subgraph is one service's portion of the schema with its own resolvers and @key directives.

"Clients query the supergraph without knowing which subgraph owns which data — the gateway handles routing automatically."

An Apollo Federation directive that marks an entity's unique identifier, allowing other subgraphs to reference and extend that entity.

"The User type in the user-service subgraph is marked with @key(fields: "id") — the orders subgraph can extend it with order history."

A technique where the client sends a hash of the query instead of the full query text. The server looks up the full query by hash — reducing bandwidth, preventing arbitrary queries, and enabling query allowlisting.

"We use persisted queries in production — clients send the query hash, not the full SDL. This blocks queries that aren't in our allowlist."

GraphQL's built-in ability to query the schema itself — asking what types and fields the API exposes. Powers tooling (IDEs, code generators, explorers). Often disabled in production to hide the schema from attackers.

"We disable introspection in production — attackers could use it to map our entire data model. Introspection is only enabled in staging."

A server-side mechanism that rejects GraphQL queries exceeding a maximum nesting depth — preventing expensive deeply-nested queries or infinite recursion in circular schemas.

"Our depth limit is 6 — deeply nested queries beyond that are rejected with a 400 error before reaching the resolvers."