In GraphQL, what does an argument on a nested field apply to when its parent resolves to many objects?

## One written argument, many applications A document is a template, not a call. When a selection set is executed against a list of parent objects, every field in that selection set is executed once **per parent object**, and the argument values written next to the field are used again for each of those executions. They are not consumed once and shared. Take a bank statements graph: ```graphql query MonthlyStatements { customer(id: "cus-4471") { accounts { iban statements(year: 2024, page: 1) { closingBalanceMinor } } } } ``` If the customer holds 7 accounts, `statements(year: 2024, page: 1)` runs 7 times. Each run gets that account's own first page of 2024 statements. The response carries 7 separate statement lists. Neither "one page of statements shared by the accounts" nor "one page spanning the accounts" is what happened. This sounds obvious written down, and it is precisely the thing candidates get wrong on a whiteboard, because the argument *looks* singular - it is one piece of text, sitting in one place in the document. ## You cannot vary the value per parent The direct consequence: within one selection, every parent gets the same argument values. There is no syntax for "12 statements for the current account, 3 for the savings one". A document can select the same field twice under different response keys, giving each selection its own arguments, but that still applies each set uniformly across all parents. When genuinely per-parent parameterisation is needed, the answer is a schema change rather than a document trick: expose a root field that takes a list of identifiers alongside their per-item parameters, so the varying values arrive as one input value rather than as arguments scattered through the tree. ## Arguments do not cascade The second consequence surprises people more. An argument on a parent field scopes **nothing** for the fields beneath it. In ```graphql accounts { statements(year: 2024) { transactions(minAmountMinor: 5000) { amountMinor } } } ``` the `year: 2024` written on `statements` does not reach `transactions`. There is no inheritance rule, no name matching, and no way for one field's arguments to reference another's. If `transactions` should be restricted to 2024, either it must be reachable only through a statement that is already scoped to 2024 by the shape of the data, or it needs its own argument. Servers can and do carry information down their own internal call chain - the object a parent produced is available when its children are resolved, and that is usually how a child field ends up knowing which year it is inside. But that is server-side plumbing, invisible in the type system. From the document's point of view each argument list is closed and local, and a schema that relies on a reader *assuming* a parent argument scopes its children is a schema that will be misread. ## The multiplicative blast radius The operational point, and the reason this is a senior question rather than a trivia one: **the cost of an argument on a nested field multiplies by the fan-out above it**. A `limit: Int = 47` on a root list field promises at most 47 items. The same declaration on a field nested under a list of 312 accounts promises up to 14,664 - from a document that wrote the word `limit` zero times, because the default supplied it. Nest that one level further and the ceiling multiplies again; a deeply nested document, twenty levels of it, can turn several small, individually reasonable defaults into a response nobody sized for. This changes how you pick argument defaults during schema review. At the root, a generous default is a convenience. On a nested list field, the same generous default is a promise made once per parent, and it is worth asking what the realistic parent count is before writing the number down. The same applies to whether a nested list field has a limiting argument at all: an unbounded nested list is unbounded *per parent*. It also changes how you read a slow request. When one document is far heavier than the shape of its text suggests, the arithmetic to do first is the product of the fan-outs and the nested arguments, and the defaults matter as much as what the caller actually wrote - a default is invisible in the document but fully present in the work. ## The mental model to state in an interview Say it as a rule: *arguments are written per field and applied per parent occurrence of that field.* Everything else follows - no cascading, no per-parent variation, and a cost that is the product of the argument's effect and the fan-out above it, not the sum.