Why this matters
- GraphQL solves over-fetching for mobile clients but introduces N+1 and query-cost risks.
- Knowing when to stay on REST avoids operational pain for simple CRUD catalog APIs.
- Spring for GraphQL reuses the same service layer — interviewers check you do not duplicate business rules.
GraphQL vs REST
L1 · FresherClients request exactly the fields they need in one round trip — useful for mobile BookStore apps with varied screens.
Spring for GraphQL
L2 · IntermediateSchema files plus @QueryMapping methods expose resolvers that call the same services as REST controllers.
N+1 in GraphQL
L3 · AdvancedBatch loaders or @SchemaMapping with DataLoader prevent one query per book author when resolving nested types.
When not to use GraphQL
L4 · ExpertSimple CRUD, caching at CDN, or file downloads often stay REST. GraphQL adds operational complexity (query cost, introspection security).
Arrows show @Autowired wiring — container injects at startup
Hook
Mobile clients want one round trip: book details, author name, and related titles. BookStore adds Spring for GraphQL so clients query exactly the graph they need instead of over-fetching REST resources.
Schema-first vs code-first
Spring GraphQL supports schema files under src/main/resources/graphql/ with runtime wiring in Java. Define types close to your domain language:
type Book {
id: ID!
title: String!
isbn: String!
price: BigDecimal!
author: Author!
}
type Query {
book(id: ID!): Book
booksByGenre(genre: String!, first: Int = 20): [Book!]!
}
The rest of this guide is part of Pro
Free covers every fresher guide in full. Pro unlocks Senior, Staff and Architect guides across every track.
Still to come · 7 sections
- Query controller
- N+1 and batch loading
- Security and depth limits
- BookStore in action
- Runnable BookStore lab
- Failure modes in production
- Subscriptions (when needed)
Test yourself
Answer these before moving on — recall is what makes it stick.