GraphQL Schema Concepts

A type defines the shape of data in a GraphQL schema, listing fields and the type of each field. Object types like User describe entities, while scalar types such as String, Int, and Boolean hold concrete values. The schema is strongly typed, so clients know exactly what they can request. Special root types, Query, Mutation, and Subscription, are entry points. This type system enables validation, introspection, and rich tooling around a single, self-describing contract.

A query is a read operation in which the client specifies exactly which fields it wants, and the server returns data shaped to match. This avoids over-fetching and under-fetching common with REST. Queries can nest related objects in a single request, traversing the graph. Because the request mirrors the response shape, clients receive predictable data. Queries are declared under the root Query type in the schema, where each field corresponds to data the client may request.

A mutation is an operation that modifies server-side data, covering create, update, and delete actions. Like queries, mutations specify the fields to return after the change, so the client can immediately read the updated state. Mutations are defined under the root Mutation type. By convention they are executed serially, unlike query fields which may resolve in parallel, preventing conflicting writes. Designing clear mutation inputs and return payloads keeps the API predictable and easy to consume.

A resolver is a function that produces the value for a single field in a schema. When a query executes, the server calls the resolver for each requested field, passing arguments, the parent object, and a shared context. Resolvers can read from databases, call other services, or compute values, which is where business logic lives. Fields without an explicit resolver use a default that reads the matching property. Composing resolvers across types is how GraphQL assembles a response from many sources.

A fragment is a named, reusable selection of fields on a particular type that you can include in multiple queries or mutations with the spread syntax. Fragments reduce duplication when several operations need the same set of fields, and they keep selections consistent. They are essential to client libraries like Relay, which colocate fragments with components so each component declares its own data needs. Using fragments makes large query sets more maintainable and ensures field selections stay in sync.