Under-fetching happens when an API response lacks data the client needs, so the client must make another request. A board-game detail view, for example, may need a game's domains and mechanics as well as its basic properties. section 10.1.2
A null field does not mean no relationship
The response for Dark Tower includes basic properties but shows boardGames_Domains and boardGames_Mechanics as null. Those values do not establish that the game has no domains or mechanics: the related data lives in separate tables and was not explicitly included in the query. section 10.1.2
A REST endpoint can address the missing data, but each option has a cost:
- Use EF Core's Include() to fetch related entities. This may suit a single-game endpoint; doing it for a large list risks over-fetching and poorer performance. section 10.1.2
- Add an aggregate endpoint tailored to the detail view, at the cost of more API code and maintenance. section 10.1.2
- Fetch the missing data through additional endpoints, requiring more client requests. section 10.1.2
GraphQL offers another approach: the client requests board-game fields together with nested domains and mechanics through one endpoint. The response contains the requested fields without a follow-up request. That flexibility has trade-offs: custom queries can add server overhead, and GraphQL does not provide native response caching. section 10.2.4 section 10.2.2
query {
boardGames(order: { id: ASC }, first:3 ) {
nodes {
id
name
year
boardGames_Domains {
domain {
name
}
}
boardGames_Mechanics {
mechanic {
name
}
}
}
}
}
This query requests basic board-game fields and the names of related domains and mechanics together; run it in BananaCakePop to check that the response needs no second retrieval. section 10.2.4
