GraphQL — Ask for Exactly What You Need

The mobile screen needs user.name, the user's last 3 orders, and each order's total. In REST: 1 + 1 + 3 round-trips, plus a lot of fields you didn't want. In GraphQL: one round-trip, exactly those fields.

query {
  user(id: 42) {
    name
    orders(last: 3) {
      total
    }
  }
}

The GraphQL server can call several REST APIs, a couple of databases, and a search engine, then return one consolidated tree. The client doesn't see the orchestration — and the orchestration logic stays in one place rather than smeared across mobile and web codebases.

Introspection means the schema is queryable. GraphiQL gives you autocomplete and inline docs in the browser. Codegen generates type-safe TypeScript hooks (useGetUserQuery) so the wire shape and the React component's types are guaranteed to match.

Everything is POST /graphql with a different body. CDN and browser HTTP caches see one URL — they can't help. Solutions: persisted queries (server stores the query, client sends a hash, request becomes cacheable GET), client-side normalized caches (Apollo, Relay, urql), or bolt on Automatic Persisted Queries to recover REST-style edge caching.

A query for "10 users and their orders" calls the user resolver once, then the order resolver 10 times — naive resolvers turn one query into dozens of database hits. The fix is the DataLoader pattern: batch and de-duplicate within a single request. Every serious GraphQL backend uses it; forgetting it is how prod databases fall over.

A client can request deeply nested fields, or 100,000 users at once. Defenses: query depth limits, complexity scoring, persisted-only queries in production (clients can only run pre-registered queries), per-operation rate limits.

• Uploads: not part of the spec. Use graphql-multipart-request-spec or pre-signed URLs to S3 instead.
• Errors: GraphQL almost always returns 200 OK with errors in the body. HTTP-level monitoring lies; instrument GraphQL errors separately.
• Status codes & auth: you give up REST's free use of 401, 403, 429, etc. Auth and rate limits live in resolvers and middleware.

Real-time GraphQL runs over WebSocket (or SSE via graphql-sse). You inherit all the WebSocket ops complexity — connection lifecycle, sticky sessions, multi-node fan-out via Redis. Often simpler to use SSE or a dedicated pub/sub service for real-time and keep GraphQL synchronous.