Challenge 2: Write an Under-Fetching Scenario — Possible Solution
====================================================================

THE SCENARIO
-------------
A recipe app's "recipe detail" screen needs to show: the recipe itself
(title, instructions), the author who created it (name, avatar), and
the list of ingredients (each with a name and quantity).

WHY THIS NEEDS AT LEAST THREE REST REQUESTS
-----------------------------------------------
1. GET /recipes/15
     -> returns the recipe's own fields (title, instructions,
        authorId, an array of ingredientIds) but not the actual
        author details or full ingredient details themselves.
2. GET /users/{authorId}
     -> a second request needed to fetch the author's name and avatar,
        since the first response only contained an ID reference.
3. GET /ingredients?ids=...  (or one GET /ingredients/{id} call PER
   ingredient, which would be even worse — an N+1 pattern of its own)
     -> a third request (or more) needed to fetch the actual
        ingredient names and quantities.

THE EQUIVALENT GRAPHQL QUERY
-------------------------------
query {
  recipe(id: 15) {
    title
    instructions
    author {
      name
      avatarUrl
    }
    ingredients {
      name
      quantity
    }
  }
}

WHY THIS WORKS
--------------
- The query mirrors the exact shape the screen needs — one root field
  (recipe) with three nested selections (author, ingredients, and the
  recipe's own scalar fields) — all resolved server-side in a single
  request, rather than requiring the CLIENT to sequence three separate
  network round trips and stitch the results together itself.
- This is precisely the "three or more separate requests to build one
  screen" pattern the chapter describes — the recipe's author and
  ingredients are genuinely SEPARATE underlying resources/records (just
  like the chapter's own user/posts/comment-count example), which is
  exactly the shape of problem GraphQL's nested query resolves in one
  round trip instead of requiring the client to orchestrate multiple
  sequential REST calls.
- Note this says nothing about how CHEAP this query is to resolve on
  the server — Chapter 5's N+1 problem is a direct continuation of this
  exact example: resolving "ingredients" for a recipe with many
  ingredients could itself trigger multiple database queries behind
  the scenes, which is a separate concern from the network-round-trip
  savings on the client side that this specific challenge is about.