GraphQL is a query language for APIs. A client sends one declarative query to one endpoint, naming the fields it needs. The response contains those fields, rather than a fixed set chosen by the server. This can avoid overfetching (receiving unwanted data) and underfetching (needing another request for missing data). section 10.2
Consider a board-game client that needs games and their related domains and mechanics. A REST API may require calls to multiple endpoints or return more fields than the client wants. With GraphQL, the client can request a combined JSON result in one round trip. The GraphQL runtime processes the standardized query; the API does not need a separate endpoint for each desired result shape. section 10.2.1
Compare the multiple-endpoint REST path with GraphQL’s single query and combined response. section 10.2.1
Try a board-game query
Request only games whose names start with “War,” ordered by name ascending and limited to ten. Select each game’s Id, Name, Year, MinPlayers, MaxPlayers, and PlayTime, plus the Id and Name of each related domain and mechanic. Test the query in the BananaCakePop web client and check that the result contains only the requested data. section 10.5.1
The flexibility has costs. GraphQL has no native caching support, and customized responses make caching harder than with typical REST endpoints. Its runtime adds overhead, while expensive client-written queries can strain the server. It also has a steeper learning curve and lacks some features out of the box. In ASP.NET Core, a package such as HotChocolate can supply GraphQL support; choose it when tailored results justify these trade-offs. section 10.2.2 section 10.6
