Spring for GraphQL

Follow one request. It arrives on the HTTP endpoint (or, for a subscription, on a WebSocket or RSocket connection) and passes through the interceptor chain, which can lift headers or the authenticated user into the request context. The execution engine parses and validates the query against the schema that `GraphQlSource` built at startup, then resolves fields top-down: root fields call controller methods, nested fields call schema mappings or read properties of the parent. Whenever a resolver asks for data through a DataLoader, its key waits in a queue until the engine dispatches the whole level as one batch. Exceptions from any resolver pass through the exception-resolution chain and become entries in `errors` next to whatever data did resolve. The rest of the hub attaches to that path: - **Pagination** wraps selected list fields so a controller can return a scrolled window of results and the framework renders it as a connection with cursors. - **Security** usually authenticates at the endpoint with the ordinary filter chain and authorizes per method, relying on the context reaching resolvers that run asynchronously. - **Federation** adds entity resolution to a subgraph, so a router can ask this service for objects by key in the middle of a plan that spans others. The core binding, with the batching that keeps it from turning into N+1: ```kotlin @Controller class BookController(private val books: BookRepository, private val authors: AuthorClient) { @QueryMapping // Query.booksByGenre in schema.graphqls fun booksByGenre(@Argument genre: String): List<Book> = books.findByGenre(genre) @BatchMapping // Book.author for every book in the response, one call fun author(books: List<Book>): Map<Book, Author> { val byId = authors.findByIds(books.map { it.authorId }.toSet()) return books.associateWith { byId.getValue(it.authorId) } } } ``` The two methods meet only through the schema: nothing in the code says that `Book` has an `author` field, so renaming either side without the other breaks the binding, not the build.

This guide assumes Spring for GraphQL on Spring Boot 3, from 1.3 onward. The project reached 1.0 in 2022 alongside Spring Boot 2.7, and several features interviewers ask about arrived later: - **1.2** added pagination support — connection types, scrolling subranges and adapters over Spring Data's scroll results — along with `@GraphQlExceptionHandler` methods and the schema inspection report that flags schema fields with no handler. - **1.3** added federation support, built on the federation library for GraphQL Java, with entity mapping methods on controllers. If an interviewer's codebase is older, say which features it would lack rather than assuming them. The annotation model for queries, mutations, schema mappings and batch mappings has been stable since 1.0, so answers about controllers and batching carry across every release line.

Spring for GraphQL sits on GraphQL Java, the engine that parses, validates and executes queries; Spring contributes the Boot auto-configuration, the annotated controller model, transports, interception, security integration and Spring Data support. Netflix DGS is the other widely used GraphQL framework for Spring applications, with its own annotation model and code generation around the same engine; a candidate should know both exist and that the concepts transfer. GraphQL itself is usually weighed against REST and gRPC. REST keeps HTTP caching, status codes and simple per-resource endpoints; gRPC suits typed service-to-service calls; GraphQL fits clients that assemble varied views from many entities in one round trip, at the price of harder caching and per-field cost control. In federated designs, Spring services act as subgraphs behind a router such as Apollo's, which owns composition and query planning. See [Federation Overview](/topics/be-spring-ecosystem-graphql-federation) for the subgraph side.