GraphQL: The enterprise honeymoon is over

Long-term experience & where GraphQL works

• Some teams report nearly a decade of success with GraphQL across many backends and frontends; they see it as past the “honeymoon” and into a stable, productive phase.
• Others tried it (often via Apollo or Hasura) and ultimately went back to REST/OpenAPI or RPC, feeling they gained little beyond extra complexity.

REST/OpenAPI, OData, tRPC, gRPC and other alternatives

• Several argue that OpenAPI with generated types and clients provides similar contract guarantees without GraphQL’s resolver and query complexity.
• Counterpoint: OpenAPI specs often drift or are too verbose unless generated or managed with higher-level tools (Typespec, codegen libraries).
• OData attracts some as a “RESTy” alternative, but others criticize its verbosity, overpowered filtering, and weak tooling.
• In TypeScript-first stacks, tRPC and gRPC are cited as nicer contract solutions when you don’t need the “graph” aspects.

What people see as GraphQL’s real benefits

• Many reject “overfetching” as the main value; they highlight instead:
  • Strong, enforced schema contracts and type-safe evolution (add/deprecate fields, deprecate endpoints).
  • API composition for M:N client–service relationships and hiding microservice/REST chaos behind a single graph.
  • Federation/supergraph for large enterprises as a coordination and governance tool, especially across many teams.
  • UI composition via fragments, colocation, and data masking (especially with Relay-style tooling).

Complexity, auth, and operational pain

• Critics emphasize resolver composition, nested permission checks, and schema sprawl as major cognitive and maintenance burdens.
• AuthZ through nested resolvers is seen as particularly hard to reason about and coordinate across teams.
• Some note that many production setups end up locking queries down (persisted queries, max depth/complexity), effectively turning dynamic GraphQL into a set of fixed RPC calls.

Client tooling: Relay, Apollo, URQL, Isograph

• Several insist GraphQL “only pays off” with advanced clients (Relay/Isograph), citing:
  • Normalized caching and fine-grained re-renders.
  • Fragment colocation and auto-generated queries.
  • Pagination, refetch, and entrypoint patterns.
• Others find Apollo/URQL plus codegen or gql.tada “good enough” and see Relay as too complex or poorly documented.

Performance, overfetching, and database concerns

• Some maintain overfetching is a real web performance problem; others say modern “enshittification” has other bigger causes.
• N+1 queries, hot shards, and adversarial queries are recognized risks; typical mitigations are query-cost heuristics, depth limits, rate limiting, and dataloader patterns.
• There’s disagreement on how much GraphQL really helps vs simply moving complexity from REST endpoints into the graph layer.

Public APIs, data warehousing, and reporting

• For SaaS/public APIs (e.g., Shopify-style), GraphQL is praised for discoverability and rich, typed access; others say schemas can become so verbose that basic operations feel harder than REST.
• Data engineers complain GraphQL is painful for bulk extraction/warehousing: they must reverse‑engineer schemas via queries, hit rate limits, and “overfetch anyway” just to get everything into a warehouse.

When people think GraphQL is a good fit

• Common “good fit” scenarios mentioned:
  • Large UI codebases with many teams/components needing independent data contracts.
  • Many microservices needing a unified access layer and federation.
  • Internal-first APIs where auth, tooling, and discipline can be tightly controlled.
• Outside those niches, many commenters feel REST/OpenAPI (or equivalent) is simpler, cheaper, and easier to secure and operate.