GraphQL

GraphQL lets the client select fields from a typed schema#

query {
  user(id: "42") {
    name
    posts { title }
  }
}

A schema defines available types and fields. Queries read, mutations request changes, and a single endpoint is conventional. A frontend can retrieve related data shaped for one screen, reducing some over-fetching and under-fetching.

Flexible queries move complexity to execution#

Each field resolves data and enforces authorization. Naively loading posts once per user creates an N+1 access pattern. Batching, request-scoped loaders, and deliberate data access can reduce that cost, but the server must still bound depth, breadth, and total query complexity.

• Authorization may be required per resource or field, not only at the endpoint.
• Arbitrary query shapes complicate cache keys and cost prediction.
• Resolvers can hide slow fan-out unless tracing shows the field-level work.
• Schema evolution needs ownership even when clients select their fields.

REST vs GraphQL is a product boundary decision#

GraphQL can fit complex, rapidly changing frontend data needs across related resources. REST can fit simple resource APIs, public contracts, conventional HTTP caching, and teams that value operational simplicity. GraphQL does not replace REST, and a straightforward CRUD application may not benefit from it.