GraphQL vs. REST for Internal APIs, Honestly

GraphQL earns its complexity when there are many different client shapes hitting the same backend with genuinely different data needs — a mobile app that wants a thin payload, a web dashboard that wants a wide one, a partner integration that wants a third shape entirely — because a single REST endpoint either overfetches for the thin clients or requires a proliferation of REST endpoints tailored to each shape. An internal API with one primary consumer usually doesn't have that problem: REST with well-designed, purpose-built endpoints is simpler to cache (GraphQL's flexible queries make HTTP-level caching much harder, typically requiring a separate caching layer keyed on query shape), simpler to authorize per-field without a custom directive system, and simpler to reason about performance for, since REST's cost is visible in the URL while GraphQL's cost depends on which fields and nested resolvers a given query happens to touch, which is why GraphQL services usually need query complexity analysis and depth limiting to prevent one client-side query from accidentally requesting an expensive resolver tree. Neither is a correctness argument against GraphQL — it's a real, well-proven answer to a real problem — the mistake is adopting it by default for internal APIs that don't have client-shape diversity, paying for flexible querying, N+1 resolver risk, and cache complexity to solve a fan-out problem that doesn't exist yet.