Resolver & Data Fetcher

The schema says what data exists; a resolver (in graphql-java terms, a DataFetcher) says how to fetch it. Spring for GraphQL lets you write resolvers as annotated controller methods that look a lot like @RestController handlers. The engine's job is to walk the client's query and call the right resolver for each field - understanding that walk is the key to using GraphQL well.

@QueryMapping: the entry points

A method annotated @QueryMapping resolves a field on the root Query type. The method name matches the schema field:

@Controller
class BookController {

    private final BookService books;

    @QueryMapping
    Book book(@Argument Long id) {          // resolves Query.book(id: ID!)
        return books.findById(id);
    }

    @QueryMapping
    List<Book> books(@Argument String topic) {   // resolves Query.books(topic: String)
        return books.search(topic);
    }
}

@Argument binds a GraphQL query argument to a method parameter. This is the entry point: when a client sends query { book(id: 42) { ... } }, the engine calls book(42) to get the root Book object.

@SchemaMapping: resolving nested fields

Here's the crucial insight: GraphQL resolves a query field by field. Once the engine has the Book, it needs to resolve each requested sub-field. Scalar fields (title, isbn) come straight off the object via getters - no code needed. But a field that requires work - like fetching the author from another service - gets its own resolver:

    @SchemaMapping                          // resolves Book.author
    Author author(Book book) {              // the parent Book is passed in
        return authorService.findById(book.authorId());
    }

The method's parameter is the parent object (the Book whose author is being resolved), and Spring matches the method to Book.author by the return type and the containing type. So for the query:

query { book(id: 42) { title author { name } } }

the engine calls book(42) → gets a Book → reads title off it directly → calls author(book) to resolve the nested Author → reads name off that. It's a traversal of the query tree, one resolver per non-trivial field.

Why per-field resolution is powerful (and dangerous)

This design is what makes GraphQL flexible: the client picks any subset of fields, and the engine calls only the resolvers for the fields actually requested. Ask for { title } and author(book) never runs. Ask for { title author { name } } and it does.

But it has a sharp edge. Consider a list query:

query { books(topic: "java") { title author { name } } }

The engine calls books(...) once → gets 20 books → then calls author(book) once per book = 20 more calls. That's the N+1 problem, and per-field resolution makes it the default behaviour. The next lesson is entirely about taming it.