news.ycombinator.com
After 6 years, I'm over GraphQL - Hacker News
joshstrange on May 30, 2024 With most tech that I screw up I assume that "I wasn't using it right" but with GraphQL I'm not sure how anyone could. The permissions/auth aspect alone is a nightmare. Couple that with potential performance issues (N+1 or just massive amounts of data) and I want nothing to do with GraphQL anymore. Everything we attempted to fix our permissions issues just caused more problems. It would break existing queries and debugging GraphQL sucked so much. … Again, fetching and updating data is easy until you need to handle edge cases. I have the same feelings about Firebase and friends. Feels like magic at the start but falls down quick and/or becomes way too complicated. GraphQL feels like DRY run amuck, "I have to keep writing CRUD, let me abstract that away", ok but now if you need special logic for certain use-cases you have a mess on your hands. Maybe GraphQL has ways to solve it but I'll bet my hat that it's overly complicated and hard to follow, like most of GraphQL once you get past the surface. … But GraphQL has everything in it to make such problems even harder. And both these projects had clear signs of "learning-on-the-go" with loads of bad practices (especially for the N+1 problem). Issue descriptions were much vaguer, harder to find in logs and performance issues popped up in the most random places (code that had been running and untouched for ages).
Related Pain Points3件
Query complexity and performance degradation
7GraphQL queries can become increasingly complex as projects grow, with deeply nested queries and over-fetching of fields leading to poor performance, extensive database joins, and slow execution times. Query complexity assessment is difficult and clients can crater performance without guardrails.
Unnecessary complexity overhead for small projects and simple use cases
6GraphQL adds significant complexity to projects through schema management, type system duplication, tooling, and infrastructure costs. This overhead is not justified for small projects, simple APIs, or cases where use cases are well-known and static. 90% of typical API use cases can be handled by simpler alternatives.
Lack of standardized error handling
5GraphQL returns HTTP 200 for most responses even when errors occur, making it difficult for clients to programmatically determine error nature. Errors are embedded in the response body without standardized error codes, forcing developers to implement custom error-handling logic and parse fragile error message strings.