Q11 proof · GraphQL schema, resolvers and execution limits

11. GraphQL: experience and context

Answer as submitted

“Yes — ~4 years: schema design, resolvers, DataLoader, subscriptions, federation.”

Technical decision: expand. The submitted line lists the topics but not the engineering behind them. This page is the separate, detailed version: it shows the schema contract, how the resolvers avoid N+1, and which limits keep arbitrary client queries from harming the database.

Expanded answer

Yes — roughly four years, mainly in enterprise back ends where a single endpoint has to serve several clients. That work covers schema-first SDL (types, interfaces, enums, input objects, cursor/Relay-style connections and explicit nullability) as well as code-first definitions in C# (Hot Chocolate / GraphQL.NET style) and Python (Strawberry / Ariadne style); resolvers with request-scoped context and DataLoader batching; execution governance with depth, cost and persisted-query allow-lists; subscriptions over WebSocket for change notifications; and per-field tracing so the slowest resolver is identified from data rather than guessed.

Decision	Typical implementation	Why it is done this way
Schema as contract	SDL with explicit nullability	Clients can only request what the model allows, and breaking changes are caught in CI.
Pagination	cursor connections, never unbounded lists	A large list cannot be requested in one query by accident.
N+1 prevention	DataLoader, batched per request	A nested selection costs a fixed number of queries, not one per row.
Execution limits	depth + cost analysis + allow-list	An expensive or unexpected operation is rejected before it reaches the database.
Error contract	`userErrors` in the payload, codes in `extensions`	Partial success is explicit and the client can degrade one field.
Live updates	subscriptions over WebSocket	Only what changed is pushed, instead of clients polling.
Observability	per-field tracing, trace id per operation	Optimisation targets the resolver that actually owns the latency.

Live GraphQL workflow proof

The running component below changes its operation/result view through real event binding. Select a step to see the schema or runtime decision, the reasoning behind it, and the measurement that proves it.

GRAPHQL WORKFLOWRUNNING

Choose a GraphQL step

Select a step to inspect the decision, the reasoning and the measured result.

$ type Order { id: ID! lines: [OrderLine!]! } · query { orders(first: 20, after: $cursor) { … } }

The schema is the contract: types, nullability and cursor pagination are designed before the resolvers, so a client can only ask for what the model allows.

SDL 412 lines  ·  breaking-change check in CI
nullable fields reviewed per query

How the API is kept predictable

Rules I apply. Design the schema before the resolvers and treat it as a published contract; paginate every list; batch every relationship through a request-scoped loader; cap depth and cost and allow-list operations in production; report domain failures as typed payload errors instead of exceptions; and trace per field so the slow resolver is found with evidence. GraphQL gives the client flexibility, and those rules are what keep that flexibility from becoming a liability.

Boundary for Q11: this page covers schema design and execution behaviour. Federation topology across many teams, gateway-level caching strategy and client-side cache normalisation are separate topics.

Source files

Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of the same decisions.

Acceptance criteria

States the years of GraphQL experience and the context it was used in.
Distinguishes schema design, resolver batching, execution limits, errors and subscriptions.
Shows an interactive proof of choosing a GraphQL step and reading its measurement.
Keeps every list paginated and every nested selection batched.
Defers federation topology, gateway caching and client cache normalisation to a later topic.