When the client controls the layout, the transport is a product decision

The requirement sounded like a frontend problem: let the owner reconfigure storefront sections from the dashboard. It is actually a transport problem, and getting it wrong costs a new endpoint for every layout the client invents.

With REST there are two options and both are bad. Return everything and let the frontend discard most of it, which is slow and gets slower as the catalogue grows. Or ship an endpoint per layout, which makes every design change an engineering ticket, which is exactly what the client was paying to avoid.

GraphQL inverts it. Layout becomes data the owner edits, and the storefront asks for precisely the shape that layout needs. Adding a section is configuration, not a deploy.

The cost is real and worth stating. N+1 resolution has to be managed deliberately rather than discovered in production, and a team that has only written REST needs bringing up to speed on schema design before they write resolvers. I made the call, specified the module split, and reviewed resolvers while people came up the curve. The decision was mine to defend, which is the part of technical leadership that does not show up in a commit history.