GraphQL

Nothing by itself. GraphQL defines no execution semantics for custom directives, so an application is validated metadata the server must be programmed to find and act on. A directive nothing reads is documentation.

A directive definition declares the directive's name, the arguments it accepts with their types and defaults, whether it may be applied more than once in the same place, and, mandatorily, the list of locations where it may be applied. It declares no behaviour.

GraphQL's own grammar has an enum-value token, so a value like STORED is written as a bare name in a document. JSON has no enum token, so the same value crosses the wire as a string holding that name.

An interface declares fields that every implementing object type must declare too, so a client can select those shared fields on the abstract type itself. A union declares no fields at all — it only lists which object types the value may be.

__typename is a built-in meta-field selectable in any object, interface or union selection set. It returns the name of the concrete object type the server resolved, as a non-null String, so a client can tell which type it received.

Eight forms: Int, Float, String, Boolean, null, enum value, list and input object. Enum values and the true/false/null keywords are written bare, and an input object's field names are unquoted, so the syntax is not JSON.

Validation compares the parsed document against the schema alone: each selected field must exist on its type, each required argument must be supplied, and each fragment must be used and acyclic. A document that fails runs no resolvers.

They let the client decide at request time whether part of its own selection is sent. @include(if:) keeps a selection only when its boolean is true; @skip(if:) drops it when true. An excluded selection is simply absent from the response.

Fragment colocation is a client convention: every view declares the fields it needs as its own GraphQL fragment, stored beside that view, and a parent composes those fragments upward into one operation per screen.

An inline fragment is an unnamed ... on SomeType { ... } block inside a selection set. You need one when a field returns an interface or a union and you want fields that exist only on one concrete type.

The schema never says which one, so the executor asks the type system at run time, once per resolved value. That hook must name exactly one object type from the abstract type's possible types.

Yes. Apart from a mutation's root fields, an executor may resolve the fields of a selection set in any order, including at the same time, because that resolution is required to be side-effect free, so order cannot change the response.

It uses a default field resolver: it reads a member of the same name off the parent value the field above already resolved - a property, getter or map key - and returns it unchanged. It performs no I/O.

Serially. GraphQL requires a mutation's top-level fields to run one after another in document order, so their side effects are ordered. A query's root fields are side-effect-free, so a server may run them in any order.

Most servers hand a resolver four things: the parent value, the coerced arguments, a request-scoped context and an execution info object. Only the first two come from GraphQL's specification; context and info are an ecosystem convention.

A join fetches parents and children in one database round trip and repeats each parent's columns on every child row. A batched loader makes two round trips: the parents, then one bulk lookup keyed by the parent ids collected during execution.

A batch key must fully determine the value on its own, be comparable by value so the loader can deduplicate it, and differ from the other keys only along a dimension one bulk lookup can vary.

A DataLoader batch function takes a list of keys and returns a list of values of the same length, with each value at its key's index. Absent keys get null; failed keys get an error value.

It memoizes by key. The first load of a key starts the backend fetch; every later load of that same key in that request gets the same result with no second fetch. It deduplicates within a request rather than caching across them.

Not when load is called. Each load queues its key and returns a pending result; the queue goes to the batch function only once execution can make no further progress, which may happen several times per request.

A normalized store keys objects by type and id, not by the operation that fetched them. When a mutation's response carries the same id with new field values, the store overwrites that entity, and every view reading it updates.

A cached field is stored under a key made of the field name plus the arguments it was fetched with, because different arguments mean a different answer. Each page, fetched with a different cursor argument, therefore lands in its own entry.

A normalized client cache shreds each response into individual objects stored under an identity key, usually the object's __typename plus its id, with nested objects replaced by references. A document cache instead stores a whole response under the operation plus its variables.

An identifier for a document the server already holds, plus the variables. A build step extracts every operation from the client source into a manifest and publishes it ahead of the release; the shipped client carries identifiers, never query text.

HTTP caches key stored responses on the request method and target URL. Every GraphQL operation is POSTed to the same path, so the discriminator — the document and its variables — sits in a body no cache reads.

Composition merges the subgraph schemas into one supergraph, so every field ends up with exactly one type. Two different named types cannot both be published, so composition reports an error and produces no supergraph at all.

One call per item is an N+1 across services, where each call is a full subgraph request. The router instead collects every item's key into a single _entities call carrying a list of representations, so a 143-item list costs one request.

One schema and one endpoint. The client sends a single operation and gets one response, and nothing in that response says which service produced which field. The split across services is a server-side arrangement the caller never sees.

A query plan is the ordered set of subgraph requests a federation router derives from one client document. Each step is a complete GraphQL operation sent to exactly one subgraph, and the router merges the results into a single response.

The gateway holds the merge configuration: renames that resolve name collisions, plus delegation rules saying which field on one service's type is answered by calling which operation on another. The stitched services stay ordinary GraphQL servers, unaware of each other.

Only message is required, a string describing the failure. An error may also carry locations pointing into the document sent, path locating the field in the response, and extensions, a free-form map for server-specific data such as a code.

It means the schema declares the failure as its own type — a union member or an error field inside a payload — so the failure arrives under data as an ordinary selectable value instead of in the response's top-level errors list.

The field cannot hold null, so the error propagates to its parent. The parent becomes null if it is nullable; otherwise the error keeps climbing, and if every field up to the root is Non-Null, data itself becomes null.

A document can carry several root mutation fields. They run one after another, and nothing wraps the group in a shared transaction, so if the second one fails the first one's write has already committed and stays committed.

Execution ran and some fields failed while others resolved. The data object holds every field that succeeded, with null in the holes; each errors entry names the field that broke via its path. Both halves are real.

A connection is an object type that wraps a paged list. It holds an edges list, where each edge carries one item as its node plus that item's opaque cursor, and a pageInfo object describing the slice.

Base64 is a convention, not a rule: the Relay cursor connections specification only requires a cursor to serialize as a String. Encoding it discourages parsing, so a client must store the cursor and echo it back unchanged.

first/after pages forward: take the first N edges after a cursor. last/before pages backward: take the last N edges before a cursor. Both slice the same fixed ordering, and neither reverses it.

The Node interface makes every implementing type expose a non-null ID field whose value is unique across the whole schema. The node root field takes one of those identifiers and refetches that object, whatever its concrete type is.

Ten per parent. A nested connection field is resolved once for every object in the outer page, and its arguments slice that parent's own children, so an outer page of 23 with first: 10 inside can return 230 leaf rows.

Removing or renaming a field, argument, type or enum value breaks clients, as does adding an argument or input field that is non-null with no default. Adding a new nullable field or optional argument breaks nobody.

The schema is the contract clients hold, not a view of storage. Designing it from the questions clients actually ask keeps types stable when tables change, and stops the shape of the database leaking into the API.

An enum makes the set of sortable keys part of the schema. An unknown value is rejected before execution, introspection publishes the legal values, and no resolver has to defend itself against an arbitrary column name in a string.

Neither half is in the GraphQL specification; both are ecosystem conventions. A single input object gives clients one variable to pass and one place to add fields later. A payload object type leaves room to return more than the record you wrote.

The specification fixes only the character grammar - a leading letter or underscore, then letters, digits or underscores - case sensitivity, and the reservation of any name starting with two underscores. camelCase fields and PascalCase types are ecosystem habit, not rules.

An alias sets the key a field's value appears under in the response, so the same field can be selected many times under different keys. Each aliased selection is executed separately, multiplying the server's work.

The GraphQL specification defines no security controls at all - only a type system, document syntax, validation rules, an execution algorithm and a response shape. Authentication, authorization, rate limiting, depth caps and cost limits are server policy.

Object types can reference each other, so the type graph contains cycles. A finite schema therefore admits documents of unlimited depth: each trip round a cycle adds one selection level, and the GraphQL specification sets no depth limit.

A GraphQL server must produce a message for every error it returns, and the simplest string available is the thrown exception's own. Nothing in the specification redacts it, so driver text, file paths and internal hostnames travel straight to the caller.

A graph reaches the same object down many paths, so a check on the root field guards one entrance only. Every other schema field returning that object is another way in, and each needs its own check.

They are lost. Neither the GraphQL specification nor the WebSocket subprotocols defines buffering, replay or acknowledgement, so a reconnecting client subscribes again from the present moment and is never told what it missed.

The GraphQL specification defines no binary scalar and no file transport. Two conventions fill the gap: a multipart request that carries the operation and the bytes together, or uploading to storage separately and passing a reference back through a mutation.

The HTTP status describes the transport, not the GraphQL result. A request the server parsed and executed answers 200 even when execution produced errors, and under the legacy application/json response type the GraphQL over HTTP draft requires 200 for every well-formed request.

A GraphQL POST body is a JSON object with up to four keys: query, the operation document text; variables, a map of variable values; operationName, naming which operation in the document to run; and extensions, an implementation-defined map.

The operation travels in the HTTP request that opens the stream: a POST body carrying query and variables, or a GET with the same values as URL parameters. An event stream is one-way, so nothing can be sent upstream afterwards.

Two inputs: the schema, as an SDL file or as an introspection result, and the client's own operation documents. It emits, per operation, a variables type and a result type shaped by that operation's selection set.

An introspection response from the same endpoint, fetched once when the tab loads. Every type, field, argument, default value and description shown in the docs pane and offered by the completion list comes from that single reply.

Because every operation shares one route, so the metric blends unrelated workloads: a few-millisecond name lookup and a multi-second report land in the same series. The number tracks the traffic mix, not any operation's health.

A schema-derived mock is a GraphQL server built from the schema alone, with no resolvers behind it. Every field returns a value invented from its declared type - a placeholder string, a number, an enum member, a short list.

Conventions the specification deliberately leaves open: a missing description, an @deprecated with no reason, a nullable item inside a list, a type no root field can reach. All of that is a valid schema; a linter objects anyway.