Challenge 1: Identify Over-Fetching — Possible Solution
====================================================================

THE SCENARIO
-------------
GET /products/7 returns 15 fields. A mobile screen only displays the
product's name and price.

WHAT'S BEING OVER-FETCHED
----------------------------
Every field beyond "name" and "price" is over-fetched — likely things
like a full description, dimensions, weight, category hierarchy,
supplier information, inventory counts, SEO metadata, related-product
IDs, timestamps, and so on. All 13 of the remaining fields are
transmitted over the network and parsed by the client, even though the
UI never reads or displays a single one of them.

ESTIMATING THE WASTE
----------------------
In general terms: if "name" and "price" together are two small, compact
fields (a short string and a number), and the other 13 fields include
things like a paragraph-length description, nested objects, and arrays
— a reasonable estimate is that the two fields the screen actually needs
might represent well under 10-15% of the total response payload size,
meaning the large majority of every response for this endpoint is pure
waste for this particular screen. On a mobile connection, where every
byte transferred costs real time and battery, and where this endpoint
might be hit repeatedly (browsing a list of many products), that
overhead compounds across every request rather than being a one-time
cost.

WHY THIS WORKS AS AN ANALYSIS
--------------------------------
- The key insight isn't "REST is bad" — REST's /products/7 endpoint is
  perfectly reasonable if SOME other client (e.g. a full product detail
  page on the website) actually needs all 15 fields. The over-fetching
  problem is specifically about ONE particular client (this mobile list
  screen) being forced to receive a shape designed for a DIFFERENT
  client's needs, because REST endpoints return one fixed shape
  regardless of which client is asking.
- This is exactly the scenario GraphQL's client-specified query shape
  solves: a query requesting only { name price } for this specific
  screen would return just those two fields, while a different query
  from the full product-detail page could request all 15 fields from
  that SAME underlying data, without needing two different REST
  endpoints or a "lite" version of the endpoint to be added specifically
  for the mobile case.