After 6 years, I'm over GraphQL

Original Article ↗ Hacker News Discussion ↗

Where GraphQL Fits (and Where It Doesn’t)

  • Many think GraphQL fits Facebook-like cases: huge app, many teams/clients, deeply linked social graph, strict auth, mostly logged‑in users, BFF layer over many services.
  • For typical CRUD apps, small–medium teams, or simple public APIs, commenters say REST/RPC is simpler, more observable, and “good enough.”
  • Several report adopting GraphQL, then later reverting to REST or RPC while keeping only “schema as contract” and type generation.
  • Others report long‑running GraphQL deployments that work well, especially when using DB‑driven tools (Hasura, PostGraphile) or as an internal aggregation layer.

Security, Auth & Rate Limiting

  • Exposing a flexible, introspectable query API increases the attack surface:
    • Need field‑level auth, query depth/complexity limits, and rate‑limiting beyond “requests per endpoint.”
    • Potential DoS via deeply nested or fan‑out queries; parsing itself can be an attack vector.
  • Some mitigate with persisted/whitelisted queries, role‑based RLS in the DB, and GraphQL “trusted documents.”
  • Critics argue that once you whitelist queries, you’re close to REST with extra complexity.

Performance, N+1 & Caching

  • N+1 is a recurring pain: nested resolvers cause many DB/API calls. Solutions: dataloaders, SQL compilation, DB‑centric tools.
  • Disagreement on severity: some see N+1 as fatal and constant; others call it overblown if data volume and query shapes are bounded.
  • HTTP caching, logging, and network debugging are widely seen as easier with REST (distinct URLs, status codes with clear semantics).

Developer Experience & Tooling

  • Frontend devs like: self‑documenting schema, strong typing, GraphiQL, fragments, and the ability to ask for just needed fields.
  • Backend devs often dislike: resolver boilerplate, mixed business logic and data loading, complex auth, and debugging query performance.
  • Apollo/Relay clients offer powerful normalized caches and co-located data requirements, but can be hard to reason about and debug.

Alternatives & Patterns

  • Common alternatives: REST + OpenAPI, tRPC, gRPC/Buf Connect, OData, JSON‑RPC, EdgeDB, DB‑backed auto‑CRUD (PostgREST, Hasura, PostGraphile), BFFs, Remix/Next loaders.
  • Several see GraphQL as solving organizational problems (frontend–backend coordination) more than technical ones; others argue that’s precisely its value at scale.

Overall Sentiment

  • Majority sentiment in this thread trends skeptical: GraphQL is powerful but high‑cost, often misapplied, and rarely the default best choice.
  • A substantial minority report strong success where constraints match (many clients, complex graphs, good tooling, disciplined schema and auth).