GraphQL
Studies in this cluster, in series order. Each one keeps its own URL.
APIs
HTTP semantics, retries, idempotency, GraphQL tradeoffs, and contract design.
GraphQL
6 studies- 1.GraphQL — Schema Design, N+1, Federation & When Not to Use ItGraphQL is a query language plus a typed schema so clients can ask for the fields they need on one endpoint. This hub is the decision map for schema nullability, resolver N+1, federation, and when REST or gRPC is the better tool.
- 2.Schema Design — Types, Nullability, Inputs & EvolutionA GraphQL schema is a versioned product contract. Nullability, input types, and additive evolution decide whether the next ship breaks clients or only adds a field they can ignore.
- 3.Resolvers & N+1 — DataLoader, Batching & Query PlanningGraphQL walks the selection set and calls a resolver per field. A child fetch per parent row is the N+1 outage. DataLoader batches those keys inside a single request, and a join or a persisted plan beats the loader when the shape is fixed.
- 4.Queries, Mutations & Subscriptions vs REST/gRPCGraphQL operations are Query for a read, Mutation for a write, and Subscription for a product event stream. Map them to REST methods and gRPC shapes, then leave CDN reads, idempotent POST retries, and mesh streams in their own clusters.
- 5.AuthZ, Complexity Limits & Abuse ProtectionA GraphQL endpoint lets the client choose depth, breadth, and aliases. Authentication at the door is not enough. Authorize each sensitive field, score the query, and prefer persisted documents for first-party apps.
- 6.Federation, Gateways & Schema Stitching TradeoffsFederation, schema stitching, and a monolith schema are ownership models. A gateway is worth it when domain teams and a platform SLO both exist. It does not remove N+1, field AuthZ, or the need for a cost budget inside each subgraph.