What does an alias do in a GraphQL query, and when do you need one?

## The response key, not the field name GraphQL's response is a plain object whose keys come from the document, not from the schema. The spec calls the key a field produces its **response key**, and defines it in one line: the alias if the selection has one, otherwise the field name. Everything about aliases falls out of that definition. ```graphql query TerminalDwell($id: ID!) { shipment(id: $id) { reference origin: leg(sequence: 1) { terminal { code } departedAt } final: leg(sequence: 7) { terminal { code } arrivedAt } } } ``` The response carries `origin` and `final`. It carries no key called `leg` at all, and the `Shipment` type in the schema has no field called `origin` — an alias is a property of the *document*, invented by the client, and it never has to exist anywhere else. ## Why the language needs them at all If aliases were only cosmetic renaming they would be a footnote. They are not, because of a validation rule the specification calls **Field Selection Merging**. Informally: if two selections in the same scope share a response key, the executor must be able to collapse them into one, and it can only do that when they name the same field with the same arguments (and, for composite fields, when their sub-selections merge too). That rule is what makes the innocent-looking document illegal: ```graphql # invalid: both selections want the response key `leg`, with different arguments shipment(id: "BKG-40913") { leg(sequence: 1) { departedAt } leg(sequence: 7) { arrivedAt } } ``` Validation rejects the whole document. There is no rule that a field may not appear twice — selecting `reference` three times is perfectly legal, and the executor simply merges the three into one key. The rule is about *conflict*, and arguments are the usual source of it. Aliasing resolves the conflict by giving each selection its own key. Nothing else changes: the server still resolves the `leg` field twice, once per set of arguments. ## Merging is what makes repetition safe The same mechanism is why identical selections can pile up harmlessly. Two parts of a document may each ask for `reference`; they merge and the field is resolved once. For composite fields the merge is recursive — two selections of `terminal` under the same key merge if their arguments match, and their sub-selections are then merged in turn, so `terminal { code }` and `terminal { city }` combine into `terminal { code city }` under a single key. This matters most in a document assembled from several pieces, where no single author sees the whole selection at once. Merging is why the pieces compose; the conflict rule is why they occasionally refuse to. ## What an alias is not * **Not a schema concept.** Aliases exist only in the document. They do not appear in the SDL, they cannot be constrained by the server, and two clients may alias the same field differently. * **Not a way to reach a different field.** `total: reference` returns the value of `reference`; the alias has no lookup power of its own. * **Not a cost saving.** Two aliased selections of the same field with different arguments are two field resolutions. A document that aliases the same expensive field forty times causes forty resolutions — which is exactly why aliasing shows up in the abuse-control conversation about a public endpoint. * **Not free for consumers.** Because the response key follows the alias, anything typed against the response — generated result types, a normalized client cache's own bookkeeping — keys off the alias, not the schema field name. Renaming an alias is a change to the response contract as far as the calling code is concerned. ## A worked case: two views of the same object A freight-tracking screen shows a shipment's declared ETA and the current carrier estimate side by side. Both come from one schema field, `eta(source: DECLARED)` and `eta(source: CARRIER)`. Without aliases the document does not validate. With `declaredEta:` and `carrierEta:` it does, and the response reads naturally: ```json { "data": { "shipment": { "declaredEta": "2026-04-18", "carrierEta": "2026-04-21" } } } ``` An interviewer following up will usually ask what happens if you alias the same field with the *same* arguments — the answer is that it is legal, produces two keys with equal values, and the field is still only resolved once per distinct set of arguments. ## What to say in an interview Define the response key first, then say the alias sets it. Give the two-arguments-one-field case as the reason aliases exist rather than presenting them as cosmetic. Mention Field Selection Merging by what it does — selections sharing a key must be collapsible — and note that aliases are document-only and never appear in the schema.