Object Types and Fields

A Stronger Contract Than JSON

A REST handler returns an object and the client finds out what is in it at runtime. If the handler renames totalPrice to amount, every consumer breaks silently until someone reads the payload. GraphQL replaces that guesswork with a type system that lives on the server.

type Product {
  id: ID!
  title: String!
  priceCents: Int!
  inStock: Boolean!
}

Each line is a promise. id: ID! says the field always exists and serializes as a string. priceCents: Int! says the value is a signed 32-bit integer, which is narrower than JSON's number and therefore a stronger guarantee than "some number will be there." The exclamation mark is the non-null modifier, covered in detail in enums, lists, and non-null.

The guarantee is enforced, not documented. When a client asks for a field the type does not declare, validation rejects the request before execution:

Validation error: Cannot query field "price" on type "Product".
Did you mean "priceCents"?

No resolver ran, no query reached the database, and the client learns the correct spelling from the error message. In REST the same mistake returns a payload with a missing key that surfaces three screens later as undefined.

Because the contract is structured data, tools can read it. Introspection lets a workbench print every type and field, a linter enforce naming rules, and a generator produce typed client code; see introspection mechanics and TypeScript code generation. The schema stops being a wiki page and becomes the source both sides compile against.

Turning Rows Into a Graph

Object types are useful alone; they become a graph when they reference each other.

type User {
  id: ID!
  displayName: String!
  orders: [Order!]!
}

type Order {
  id: ID!
  placedAt: String!
  buyer: User!
  items: [OrderItem!]!
}

Two structural facts follow, and they are the reason the technology carries the name it does.

References are just fields. User.orders and Order.buyer point at other object types, so a client can walk from a user to their orders and back to the buyer in one operation. REST would answer that with either embedded JSON that duplicates data or a second call the client has to discover and make.

Cycles are legal. User -> Order -> User is a valid schema, and so is a self-reference such as User.friends: [User!]. The type system describes shape, not traversal; preventing a client from looping forever is a separate concern handled by query depth limits rather than by forbidding the cycle in the schema.

A few rules keep the graph coherent:

• Field names must be unique within a type; two title fields on one type are a schema error, not an overload.
• Object-typed fields must declare their sub-selection in queries, while scalar and enum fields must not, so the shape of every request is unambiguous.
• Arguments attach to fields, which is how a single field like orders(status: OrderStatus) serves many queries; see field arguments design for how to shape them.
• Names beginning with a double underscore are reserved for introspection (__typename, __schema, __type). Declaring __internalId in your own schema collides with machinery the platform owns, so tools reject it.

The design question you will actually face is not syntax but granularity: which relationships become fields, and which stay behind an argument. Getting that wrong produces a schema where every query triggers a full traversal, and that is a performance decision dressed as a typing decision.

Validation Runs Before Any Resolver

The pipeline behind a GraphQL request is parse, validate, execute. Object types are what make the middle step powerful, so it pays to know exactly what validation checks and what it deliberately does not.

What validation guarantees:

What validation cannot check: whether your resolvers return data of the declared type. The schema describes intent; the resolver is where intent meets the database. A priceCents: Int! resolver that returns a string produces an execution-time field error rather than a validation error, which is why the two categories must be kept separate when you debug.

Practical consequences for a team:

• Reviewing a schema pull request reviews the API surface itself, because that text is what clients compile against.
• Broken client queries fail in CI or in the workbench, not in production.
• Empty selection sets are rejected: a query must ask for at least one field, so query { product(id: "1") { } } never reaches execution.

Interview angle: "a client requests a field that does not exist; what happens and how do you know?" Answer with the phase (validation), the absence of side effects (no resolver, no database call), and the tool that surfaces it (the same validation rules that run in CI and the workbench).