graphql-schema-designlisted

# GraphQL schema design GraphQL lets clients request exactly the data they need in one round trip, shaped by a typed schema. Its power (flexible client-driven queries) is also its trap (N+1 resolvers, unbounded query cost); good schema design models the domain well and defends against the failure modes GraphQL uniquely enables. ## Method 1. **Model the schema on the domain graph, not the database.** Types and their relationships reflect how the domain connects (a user has posts, a post has comments), letting clients traverse naturally: this is GraphQL's strength over REST's fixed endpoints. Design from the client's questions and the domain (see domain-driven- design), not by mechanically exposing tables. 2. **Solve N+1 with dataloaders from day one.** GraphQL's nested resolvers naturally produce N+1 queries (resolving 100 posts, then 100 separate author queries: see n-plus-one-queries): batch and cache within a request with dataloaders (collect the IDs, fetch in one query). This is not optional optimization; it is required architecture, because the N+1 is inherent to how resolvers execute. 3. **Paginate with cursors via the connections pattern.** Lists use cursor-based pagination (the Relay connections spec: edges, nodes, pageInfo: see api-pagination-design) for stable pagination over changing data; offset pagination breaks as items shift. Bake pagination into list fields from the start; retrofitting it is a breaking