Pagination & Object Identity

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.

None. The GraphQL specification defines the type system, documents and execution, not pagination. first and after come from the Relay cursor connections convention; offset and limit are ordinary field arguments a schema author declares and a resolver implements.

PageInfo carries four fields: two non-null booleans, hasNextPage and hasPreviousPage, and two nullable strings, startCursor and endCursor. The cursors are nullable because an empty page has no edges, so there is no first or last cursor to report.

No. The Relay cursor connection specification fixes edges, node, cursor and pageInfo; it allows extra fields but defines no totalCount. totalCount is a near-universal server convention whose meaning — exact, capped or estimated — each schema decides for itself.

A cursor names a position in an ordered list. If two rows compare equal on the sort key, that position is ambiguous, so the next page can repeat or skip rows. Appending a unique column makes the order total.

That row's value for every field the connection sorts by, plus a unique tie-breaker. The server turns those values back into a keyset comparison — rows strictly after this position in this order — instead of skipping a count of rows.

The page read stops after one page of rows; the count must visit every row matching the filter, so its cost scales with the match set, not the page. Selecting the field is what makes a client pay for it.

Rows that tie on the timestamp have no defined order among themselves, so a cursor inside that block names no single position. Depending on the resume comparison, the client sees the tied rows twice or misses them entirely.

A cap on the whole lookup is a global cap: its rows can all belong to one parent, leaving the rest with empty pages and hasNextPage false. Each parent needs its own top-N slice.

Facts about the relationship between the parent and the item belong on the edge; facts about the item itself belong on the node. The test is whether the value changes depending on which parent you reached the item through.

Only a negative first or last is an error the Relay pagination algorithm mandates. Supplying both first and last is discouraged but defined. Neither count, and a request above your maximum page size, are unspecified — the server decides.

Because one lookup field has to resolve identifiers for every type, the value must say what it points at as well as which row. Opacity keeps the encoding the server's to change, since no caller is entitled to read it.

With a second operation that fetches just that one parent and passes that parent's own endCursor to its nested connection. Each nested connection has its own pageInfo and cursors, meaningful only inside the connection that produced them.

The Relay server specification only requires hasPreviousPage to be accurate when a client pages backward. Paging forward, a server may answer true only if it can cheaply tell that earlier items exist, and false otherwise. False therefore means no, or unknown.

Selecting nodes skips the edge layer, so clients lose every per-item cursor and every field the edge carries. They can still resume from the slice's boundary cursor, but never from an arbitrary item in the middle.

Nothing, if the cursor carries the row's sort values: it names a coordinate in the ordering, not the row, so the scan resumes at the same boundary and finds it empty. Only a cursor holding a row reference breaks.

Treat a decoded cursor as untrusted input. Bind values as parameters, carry a fingerprint of the ordering and filters so a replay under different arguments is rejected, and compose the authorization predicate into the same query the cursor seeks within.

Flip the ordering and the keyset predicate to read the tail, take N rows, then reverse those rows back before building edges. The fetch order is an implementation detail; the response must stay in the connection's declared order.

Never in one deploy. Identifiers already handed out live in caches, links and other systems, so the server accepts both encodings for a long overlap, emits only the new one, and retires the old decoder when measured legacy traffic reaches zero.

Offset names a position, not a row. Between the two requests the ordering shifted — an insert before the window, or tied rows swapping places — so one row landed in both pages and another landed in neither.

Because the naive implementation answers it with a second query that counts or scans every row matching the filter, which grows with the data while the page query stays bounded. Fetch one row more than the page size instead, and drop it before building edges.

Start from what the UI needs. Infinite scroll needs only hasNextPage, which the page read already provides. Otherwise offer a capped count, a clearly named estimate, or a count delivered separately so it never blocks the page.

The server must choose one total order, use it for every request of that field, and document it. "Whatever the backend returned" is not an order — it can differ between two identical requests, which makes every cursor meaningless.

Budget the product, not each field. Caps that look reasonable in isolation compose multiplicatively, so shrink defaults and maxima with depth, decide per field whether a nested connection is offered at all, and roll any tightening out behind usage telemetry.

Encode the position in the opaque cursor. The server emits base64 of "offset:42", decodes an incoming after cursor back to a number, and slices with skip and take. The cursor anchors a position, not a row.

Fix meaning by name, not by hope: one name reserved for exact counts, distinct names for capped and estimated ones, mandatory descriptions, nullability everywhere. Enforce it with schema linting at publish time, because composition never checks semantics.