GraphQL
The most recommended of 5 query languages
Recommended for letting clients request exactly the nested data they need in one call, with typed schemas and generated clients. Critics often say it adds complexity and is overused where simpler APIs would do.
Recommended for letting clients request exactly the nested data they need in one call, with typed schemas and generated clients. Critics often say it adds complexity and is overused where simpler APIs would do.
89 people gave an opinion
- recommend it
- 52
- criticize it
- 37
- approval share
- 58%
Recommended in 9 of 13 months
- November 2025: recommended
- December 2025: recommended
- January 2026: recommended
- February 2026: recommended
- March 2026: not recommended
- April 2026: recommended
- May 2026: recommended
- June 2026: not recommended
- July 2026: recommended
- August 2026: not recommended
- September 2026: recommended
- October 2026: recommended
- November 2026: not recommended (month in progress)
Why it doesn’t carry the badge
- 52 people recommend itNeeds 10 or more, met.
- 1.4 recommenders for every criticNeeds 2 to 1 or better, not met.
- Recommended in 9 of 13 monthsNeeds 4 or more, met.
The same three rules apply to every product, and the badge can’t be bought. How the badge works
What people say about it
The reasons people give, with the number of comments that give each one. Open a reason to read what they said.
Why people recommend it
Each mark is one comment
Combines related data in one query
“it's useful for solving a couple of problems that large organizations at scale have like over-fetching and a single network call rather than multiple REST calls”
Comment from 17 Apr 2026 in “Ask HN: Does meta regret using GraphQL?” “you ask for specific nested structure of the data, which can span many joins across different related collections”
Comment from 24 Nov 2025 in “Claude Advanced Tool Use” “GQL gives that to me in one query, and the fundamental properties of what makes GQL GQL are what enables that.”
Comment from 15 Dec 2025 in “GraphQL: The enterprise honeymoon is over” - Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over”
- Comment from 20 Nov 2025 in “Show HN: Guts – convert Golang types to TypeScript”
- Comment from 15 Dec 2025 in “GraphQL: The enterprise honeymoon is over”
Fetches only the fields requested
“it's useful for solving a couple of problems that large organizations at scale have like over-fetching and a single network call rather than multiple REST calls”
Comment from 17 Apr 2026 in “Ask HN: Does meta regret using GraphQL?” “The agent only receives the minimal amount of data as per the graphql query saving valuable tokens.”
Comment from 24 Nov 2025 in “Claude Advanced Tool Use” “select all fields except for a base64 picture of that user, so that the request is more performant”
Comment from 13 Nov 2025 in “When Performance Matters, Skip the ORM” - Comment from 18 Sep 2026 in “Rate limits on GitLab.com are changing”
- Comment from 30 May 2026 in “MCP Is Dead”
Eases API evolution and composition
“what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution”
Comment from 15 Dec 2025 in “GraphQL: The enterprise honeymoon is over” “GraphQL has allowed us to not feel bad about adding extra properties and object to the response”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over” “the way it has scaled over time -- across backend and frontend -- has worked amazingly well”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over” - Comment from 15 Dec 2025 in “GraphQL: The enterprise honeymoon is over”
Typed schema and generated clients
“where you can have the server and client agree on what to ask for and what you'll get, be compiled away is so nice”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over” “Easy to grok, easy to build types for various languages and keep everything in sync.”
Comment from 18 Nov 2025 in “Show HN: Guts – convert Golang types to TypeScript” “Automatic type a client generation that is extremely mature.”
Comment from 1 Dec 2025 in “React and Remix choose different futures”
What people warn about
Each mark is one comment
Adds complexity and slows building
“We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over” “Something that would be a handful of lines of code in a different stack ends up being hundreds in this one.”
Comment from 21 Jun 2026 in “Code duplication is far cheaper than the wrong abstraction” “suddenly you need a whole team of devs knowing all kinds of unecessary abstractions”
Comment from 11 May 2026 in “I'm going back to writing code by hand” - Comment from 15 Dec 2025 in “GraphQL: The enterprise honeymoon is over”
Overused where benefits are small
“that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over” “shove GraphQL into application stacks and environments where you gain very little benefit”
Comment from 27 Apr 2026 in “Branimir Lambov from IBM on Cassandra” Replacing REST made things worse
“Why they needed to replace the good old REST interface, which was working perfectly, I will never understand.”
Comment from 1 Dec 2025 in “React and Remix choose different futures” “it's practically easier and better to ask teams to rebuild their APIs in REST than update the graphql”
Comment from 14 Dec 2025 in “GraphQL: The enterprise honeymoon is over”
Other query languages people recommend
The four most recommended other query languages, with the same counts for each, so you can compare like for like. The tick on each bar marks the 2 to 1 line the badge needs.
See all 5 query languages, rankedWhat people said
40 of the 104 comments that mention it, newest first. Each links to the original comment.
“The schema system and field selection is really powerful that you can pick partial results”
“I've found that it's so good that I cancelled building an an MCP server”
“GraphQL, Jest, Llama (one of the first open weights models) and more”
“i used graphQL since it allows you to embedd your github contribution history as an isometric city”
“Something that would be a handful of lines of code in a different stack ends up being hundreds in this one.”
“Graphql allows an agent to select which fields it wants in context.”
“suddenly you need a whole team of devs knowing all kinds of unecessary abstractions”
“shove GraphQL into application stacks and environments where you gain very little benefit”
“it's useful for solving a couple of problems that large organizations at scale have like over-fetching and a single network call rather than multiple REST calls”
“GraphQL is a really powerful query language, Fragments are extremely powerful, and the ecosystem is very healthy with multiple vendors”
“That's the beauty of GraphQL — each object can store its ID however it wants”
“offers a solution that adds complexity and makes everything take longer to build”
“makes long term management of network of APIs much easier”
“GraphQL doesn't justify itself unless you're using a client like Relay”
“GQL paved the way for a lot of ergonomics with our microservices.”
“GQL gives that to me in one query, and the fundamental properties of what makes GQL GQL are what enables that.”
“what GraphQL solves as main problem, which I haven't got good alternative for is API composition and evolution”
“it's practically easier and better to ask teams to rebuild their APIs in REST than update the graphql”
“GraphQL has allowed us to not feel bad about adding extra properties and object to the response”
“that benefit is not unique to graphql, so by itself, that is not a compelling reason to choose graphql”
“GraphQL is still an amazing example of good product infra API design”
“if you haven't used GraphQL with Relay you probably haven't experienced GraphQL in a way that truly exploits its strengths.”
“having hard, unbreakable lines in the sand (vs. something you have to roll your own, or which is done by convention) is important IMO”
“where you can have the server and client agree on what to ask for and what you'll get, be compiled away is so nice”
“I believe their API would've been messier if they kept the REST endpoint.”
“it's definitely saved us from things that were "impossible" to associate in our microservice backend.”
“We are paying that same complexity tax you described, but without the benefit of needing to support thousands of unknown 3rd-party developers.”
“the way it has scaled over time -- across backend and frontend -- has worked amazingly well”
“Automatic type a client generation that is extremely mature.”
“Why they needed to replace the good old REST interface, which was working perfectly, I will never understand.”
“which is what GraphQL does really well with the caveat that whatever you decide to do is certainly not natural to these LLMs”
“the claim it’s better for tool and api use by agents follows from common sense”
“you ask for specific nested structure of the data, which can span many joins across different related collections”
“teach an LLM your GraphQL query language to let it selectively load context”
“a server capable of serving any subset of the entire schema at a time (pain in the ass)”
“I do think that using graphql will solve a lot of problems for people”
“The agent only receives the minimal amount of data as per the graphql query saving valuable tokens.”
“graphql solves a lot of other problems when querying microservices”
“Easy to grok, easy to build types for various languages and keep everything in sync.”
“select all fields except for a base64 picture of that user, so that the request is more performant”
Counts come from 1,795,640 Hacker News comments, November 2025 to November 2026. How we count. Report a mistake.