How do you keep a demand-oriented GraphQL schema from degenerating into one field per screen?

## The failure mode this question is about Demand-oriented design says: start from what clients need. Taken too literally, it produces a schema that is a directory of the current user interface. On a job-board graph that looks like a `Query` with `candidateHomeScreen`, `savedSearchPage`, `employerDashboardV3`, `applicationDetailPage` — twenty-odd root fields, each returning a type built for exactly one view, each with a `header`, a `sections` list and a `footer` that mirror the layout of that page in the release it was designed for. It feels productive for one quarter. It has three costs that arrive together. **Redesigns become schema changes.** The page is the unit, so moving a widget between pages moves fields between types, and the schema churns at the rate the design churns — which is much faster than the domain does. **Nothing composes.** Two views that are eighty per cent the same get two types with two independent sets of fields, resolved twice, tested twice, and drifting apart. The second client platform — a native app whose layout differs — cannot use either, so it asks for a third. **The schema stops teaching.** A newcomer reading a demand-oriented schema should learn what the business contains: postings, employers, candidates, applications, stages. A screen-shaped schema teaches them what the web app looked like in the release when each field was added, including the pages that no longer exist and whose fields nobody dares remove. ## The durability test The practical guard is a question asked of every proposed root field or type, at review time, before it is merged: 1. **Would it survive a redesign?** If the page were rebuilt from scratch tomorrow, would this field still be the right thing to ask for? `applicationDetailPage` fails. `application(id:)` passes. 2. **Could a second client with a different layout use it?** Not "could it call it" — could it be *served* by selecting a subset or a superset of it. If serving the second surface requires a new entry point rather than a different selection, the first one was a screen. 3. **Is it named for a thing or a place?** A concept from the business domain passes. A noun from the navigation menu fails. This is the cheapest of the three and catches most of them. 4. **Does it already exist under another name?** Screen-shaped fields multiply because nobody notices that the concept is already in the graph. A field that fails these is not necessarily rejected — it is redirected. The demand is real; the shape is wrong. ## Where view-specific shape belongs The pressure behind screen-shaped fields is genuine: a view really does want one request that returns exactly its data and nothing more. GraphQL already provides that, on the client side. The document a client sends *is* the screen-shaped artefact — the selection set names precisely the fields that view needs, and where a component owns part of the view, its demand can be expressed as a named fragment that composes into the document the page sends. That is view shape living in the client's repository, where it changes at the pace of the design and is deleted when the page is. Saying this in an interview is what separates a senior answer from a slogan. "Model concepts, not screens" is a slogan. "Model concepts, and let documents and fragments carry the screen shape" is an architecture, and it explains why the constraint costs the client nothing. ## When a view-specific field is the right answer Be careful not to over-apply the rule; interviewers usually probe this next. A field whose value is a genuine computation the server owns is a concept even if exactly one surface consumes it today. A ranked feed of recommended postings for a candidate is not a screen; it is a domain capability that happens to be shown on the home page, and it belongs in the schema — as `recommendedJobs`, not as `homeFeed`. The distinguishing marks: it computes something a client could not assemble itself from other fields, its name would still make sense if the page were deleted, and a second surface (a weekly digest, an email) could plausibly want the same values. Similarly, a legitimately expensive multi-source aggregate is not a reason for a screen field. One document already spans several backends in one round trip; that composition happens during execution, not by pre-baking a view type into the schema. ## Cleaning up an existing one If you inherit twenty-seven root fields of which nine are screens, do not propose a rewrite. Get per-field usage evidence so you know which are actually selected and by whom; introduce concept fields alongside the screen fields; migrate one client at a time to selecting from the concepts; and only then start the deprecation of the screen fields, oldest and least-used first. The schema shrinks, slowly, without a single coordinated release — which is the only way this ever actually gets done.