Why does GraphQL split types into input and output kinds, and which kinds sit on both sides?

## Two families, and one overlap Every named type in a GraphQL schema belongs to one of these groups: - **Output types**: scalars, enums, object types, interfaces, unions - plus any list or non-null wrapping of those. - **Input types**: scalars, enums, input object types - plus any list or non-null wrapping of those. The overlap is exactly **scalars and enums**. Output-only: object types, interfaces, unions. Input-only: input object types. That asymmetry is the whole subject, and interviewers use it because a candidate who has only ever consumed a schema often has not noticed there are two kinds of "object" in it at all. ## Where an input type is required Four positions in a schema demand an input type, and it is worth being able to list them: 1. the type of a **field argument**, on any field, at any depth; 2. the type of a **directive argument**; 3. the type of a **field of an input object type** - recursively, all the way down; 4. the declared type of a **variable** in an executable document. Everything else - the type of a field on an object type or interface, a union member - is an output position. ## Why an object type cannot cross over The reason is not arbitrary. Three properties of an output object type are meaningless on the way in: **Selection.** A client never receives a whole object type; it receives the fields it selected. An incoming value is the opposite: it is complete as sent, with nothing to select from. There is no notion of "the caller supplied part of this object and would like the rest resolved". **Resolution.** A field on an object type can itself take arguments and is produced by running server code. `Compartment.currentParcel(includeReturned: Boolean)` describes work the server does. A value arriving from a client is data, not work to be run, so field arguments have no meaning there. **Discrimination.** An interface or a union is resolved to a concrete member at runtime, by the server, and the answer is reported to the client as `__typename`. An incoming JSON value carries no such marker, and the specification defines no input-side discriminator, so there is nothing that could decide which member of a union a supplied value is. That is why there is no such thing as an input interface or an input union. ## What an input object type is An input object type is therefore a deliberately plainer construct: a named set of fields, each typed as an input type, with no arguments, no selection sets, no interfaces implemented, no union membership and no resolvers. It is a value tree, and it can nest, be listed, and carry default values and descriptions. ```graphql input ReserveCompartmentInput { lockerId: ID! size: CompartmentSize! holdUntilIso: String notify: NotifyPreferenceInput } ``` `CompartmentSize` here is an enum - legal on this side precisely because it is a leaf value. `NotifyPreferenceInput` is another input object, nested. What you may not write is `compartment: Compartment!`, where `Compartment` is the object type the graph returns. ## The consequence: parallel type families Because a single name defines a single type, you cannot have `Compartment` be both. Every schema of any size therefore grows an input-side family alongside its output side, conventionally suffixed `Input`. That suffix is a convention that tooling and reviewers rely on; nothing in the type system requires it, and nothing enforces that `CompartmentInput` resembles `Compartment` in any way. A useful reframing for an interview: an input object is not "the writable version of an entity". It is the argument shape of one operation that happens to be about that entity, and its fields are chosen for the operation, not copied from the output type. ## When the rule bites The check happens at **schema build time**. A schema that declares an argument typed as an output type is invalid, and a conforming server refuses to build it rather than failing on the first request. So this is a class of mistake you meet while writing SDL or wiring a code-first schema, and it never reaches a client. In a code-first setup the same error usually surfaces as a startup failure complaining that a type is being used in an input position, which is worth recognizing for what it is: the same rule, reported by a different messenger. ## The compact answer Values in, selections out. Leaf types are shared because a leaf value has no direction; anything with fields the client selects, or resolvers, or a runtime type, exists only on the way out.