In GraphQL, why do per-view queries produce a request waterfall, and what does fragment colocation change?

## Why per-view fetching serialises If each view fetches for itself, a nested screen does not issue N requests in parallel. It issues them in a **chain**, because each request's variables are values from the previous response: ```pseudocode render OrderScreen(orderId): order = fetch("{ order(id: $orderId) { id status courierId } }") # round trip 1 render CourierCard(order.courierId): courier = fetch("{ courier(id: $cid) { displayName etaMinutes } }") # round trip 2 render CourierRating(courier.id): rating = fetch("{ courierRating(courierId: $id) { stars } }") # round trip 3 ``` `CourierCard` cannot even be mounted, let alone form its query, until `order` has returned - so the requests are separated by full round trips, and the screen's time to last paint is roughly `depth x RTT` plus server time, not `max(request)`. On one order-tracking screen with 14 data-bound views nested 6 levels deep, that shape produced 9 distinct operations and 1,743 ms to last paint at the 75th percentile on mobile. Composed into a single colocated document of 118 fields, the same screen paints in 386 ms. The composed request is far larger than any of the nine it replaced; it is still four times faster, because the cost that dominated was serialised network latency. Three secondary costs travel with the waterfall. Each hop repeats authentication, parsing and validation. The same entity is often fetched by several views independently, and any per-request batching the server does is scoped to a request - so nine requests means nine tiny batch windows instead of one wide one. And the UI shows a cascade of spinners appearing in sequence, which reads as slowness even where the total is acceptable. ## What colocation changes structurally The important word is **static**. Under colocation, the fields the whole tree will render are known from the composed document before rendering starts, so the screen root can ask once. Composition happens when the code is written, not when components mount. Nothing about the render tree is negotiated with the network any more. That also widens every request-scoped optimisation the server has: one authentication pass, one validation pass, one request-scoped batch cache covering the whole screen rather than a slice of it. ## The tradeoffs a senior is expected to raise **One shared latency budget.** A single response is delivered when its slowest field is done. If the delivery-history panel joins a cold analytics store and takes 1.4 s, the status chip waits 1.4 s too - which the waterfall, for all its faults, did not do. Two answers exist. The first is **incremental delivery**: `@defer` on a slow fragment spread (and `@stream` for a long list) lets the server send the rest immediately and the deferred payload later. These are incremental-delivery additions on the specification's working track rather than settled parts of the released editions, and they need matching server and client support, so treat them as a capability to verify, not to assume. The second is simply **not composing everything**: keep a second operation for the slow or optional panel. Colocation is compatible with that - it says fragments compose upward, not that a screen may only have one root. **Blast radius.** A field error deep inside one view's fragment can null more of the response than that view, depending on nullability, so one panel's failure becomes a wider hole than it would have been as its own request. Budgeting nullability for that is its own discipline. **Static limits.** A composed screen document is bigger and deeper, and a server enforcing depth or cost caps may reject at 118 fields what it accepted at 13. That is a conversation with whoever sets the cap, not a reason to fragment the screen back into a waterfall. **Invisible UI.** Fragments for tabs, modals and drawers that are not on screen still ship their fields unless the spread is conditioned on a variable. **It does not fix server-side fan-out.** Asking for a list's children in one document still causes per-item backend work unless the server batches; colocation changes the number of HTTP round trips, not the number of database calls. ## How to prove it in an interview Say what you would measure. Count **operations per screen render**, not bytes; look for the stair-step in a network timeline where each request starts after the previous one finishes; compare time to last paint before and after. And be clear that "one request per screen" is a default, not a law - the goal is that no request waits on another for data it did not need.