13 ms·

Eight Years of GraphQL

94 points by fagnerbrack 2y ago

troupo 2y ago
I think that instead of addressing and correcting the original post the author validated and confirmed everything that was said in that original post.
- fleshgrinder 2y ago
  Glad I'm not the only one who feels that it's handwavy and full of excuses.
- RedShift1 2y ago
  I think you missed the point, most of the problems that affect GraphQL APIs you will also experience with REST APIs, or any kind of APIs.
- AWebOfBrown 2y ago
  I think that's demonstrably false. His point about the runtime complexity of an API being entirely distinct from how the interface to it's code is exposed (whether GraphQL or REST or otherwise) is fairly obvious, I think. The counter-argument is that unlimited query complexity makes it far bigger problem, and the author's point is that if you're using it for private APIs with persisted queries, you shouldn't have that problem unknowingly. Don't get me wrong - I think the takeaway is that GraphQL's niche is quite small, and he's defending exactly that niche. It's not often the case that you can develop an API in a private manner which doesn't undercut higher-order value in the future, as the rise of AWS hopefully made evident.
georgyo 2y ago
Wait, people are using graphql for private, not exposed, backend apis? Who would torture themselves like that? Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs? Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed. Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically. I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.
- tossandthrow 2y ago
  Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security. Oh, and we get DB schema to frontend propagation of changes to the type. This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability. I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.
  - vosper 2y ago
    Would you consider this solution for a public (enterprise/B2B, not public-on-the-internet-for-anyone) API? I may need to build a public API that lets customers select certain fields from a variety of objects with many fields.
    - tossandthrow 2y ago
      Hmm, this is a really good questions and would definitely require a bit more information about the customer relation to fully answer. In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that? I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed. Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).
      - vosper 2y ago
        Thank you for that. You’re right that there will need to be long-term support of API versions (or at least the current one and maybe the previous one). My instinct is to give the users the full objects and let them select the fields they want on their side. It’s less work on our side. Also I’m not sure about customer comfort with GraphQL.
lukevp 2y ago
The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to release changes that are not backwards compatible as long as you can coordinate the release of the two. Then there’s no need to version at all. Sounds like this is harder with graphql than REST.
- nesarkvechnep 2y ago
  You probably mean JSON over HTTP when saying REST but the original idea of REST is painless evolution. No vX in the URL.
- rbalicki 2y ago
  Certainly, if you can either force your clients to refresh their browsers or can tolerate clients breaking, that works! That might work great for internal tools, for example (as long as no work is lost when you refresh, or you can just expect your employees to redo the work). But it’s not tenable for anything that customers use.
loveparade 2y ago
Eight Years of GraphQL, and I have yet to find a single use case for it in my projects. I've had to interact with external GraphQL APIs a few times and each time it has been a terribly painful experience. Funnily enough, for the few queries where GraphQL would've actually been useful to get some deeply nested data structure, it was usually impossible to use it because the "query is too big/deep" or it had cycles
- PUSH_AX 2y ago
  Are any of your APIs used by multiple consumers? This was the strongest use case I found personally.
robbyiq999 2y ago
GrahpQL was something that came up heavily in Front-End job ads and maybe even mentioned during my experience interviewing around 2017-2020 I was once even turned down for not having enough "GraphQL Experience" - Whatever that was. This was during a particularly painful 6 month rut for me - job search wise. It's absolutely infuriating that the tide has now changed. GraphQL doesn't matter. Did it ever? What was the point?
- treve 2y ago
  Web development goes through annoying hype cycles. GraphQL has great use-cases but it was overvalued. Unfortunately even if you recognize it you can't always avoid it if you want to be competitive in the market. Cynicism can be a trap with this stuff because it may just make you less hireable.
  - ecjhdnc2025 2y ago
    I personally think GraphQL delivered on quite a lot of its hype, and I have become a bit more forgiving of web dev hype cycles in the light of crypto, NFT and generative-BS hype cycles...
    - treve 2y ago
      In my opinion the GraphQL 'wake up call' (if we can call it that) has less to do with its intrinsic value. With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad. However I think we've seen a lot of 'GraphQL as the default paradigm from the get-go', which I think is a trap and has caused a fair bit of pain for all the small startups out there that were sold on this.
      - megadal 2y ago
        > With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad. If a framework requires you to be just as, if not more competent in its niches to achieve the same end you could've achieved without it, I think that makes it bad. That's like if an HTTP framework could only be effective at the protocol level with a team competent in HTTP. The whole point of a framework is abstraction. I have never once seen how GraphQL (the language) provides any sort of abstraction that the general framework itself doesn't, and the little abstraction GraphQL the framework does provide you can mostly sum up by just generating an OpenAPI over a set of schemas, with a whole host of benefits and few trade offs (on the implementation side, which is where your 10x devs usually live anyways). It's weird. It's like the main benefit of GraphQL is that there are groups of developers who understand it, but the biggest drawback is that it is needlessly complex, which again, seems to indicate GraphQL is bad. It's an abstraction that creates needless complexity (that you necessarily can't reverse because it's apart of the spec..)
chx 2y ago
I never understood the point. Really don't. GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response. If you are already built those then might as well just include the data necessary and use a REST API.
- ecjhdnc2025 2y ago
  It depends on whether your chosen platform can do it. If you're coding resolvers by hand, that is not fun. But for example the Lighthouse GraphQL layer for Laravel (it's a schema-first thing based on the Webonyx PHP GraphQL reference implementation) can do a lot of this for you using schema decorations. https://lighthouse-php.com https://lighthouse-php.com It has where/filter/sort/pagination, automatic scope narrowing etc., and you have very little code (if any) beyond the graphql schema to set it up. It integrates brilliantly with the Eloquent query builder. One of the best applications for PHP IMO; it is really enormously productive.
- cheema33 2y ago
  > GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response. GraphQL is just the protocol. It is up to implementations to add support for it. We use Hot Chocolate GraphQL server with entity framework backend, and it has built-in support for all of those things. Vast majority of the criticism of GraphQL comes from people who do not understand it. GraphQL does have a steep learning curve.
est 2y ago
GraphQL is painful. I am thinking some SQL but with more access control would be better.
- resonious 2y ago
  Completely agree. Most GraphQL interfaces are papered over a relational database that speaks SQL. It seems ridiculous to me to have 2 query languages on top of one another like this. Feels like any GraphQL system could've just exposed their SQL directly for way less code and more flexibility. Though I guess the layer in between lets you change your SQL schema without changing the GraphQL schema.
  - noisem4ker 2y ago
    > the layer in between lets you change your SQL schema SQL has got views for that.
elmigranto 2y ago
So if most of the issues with GraphQL are the same as with the other approach, what is the point of GraphQL that justifies all the complexity?
- rbalicki 2y ago
  Fragment composition. See my comment here https://news.ycombinator.com/item?id=40984066 https://news.ycombinator.com/item?id=40984066
bcherny 2y ago
A lot of people in this thread are criticizing GraphQL. The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta. To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc. But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally. At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc. It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases. My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.
- cheema33 2y ago
  GraphQL is particularly useful for data intensive applications. That is what we use it for. I frequently see people try to use it for simpler applications and give up quickly because it does have a steep learning curve, if you are trying to do it right both on server and client.
vlugovsky 2y ago
One of the useful things I learned from a professor at my university is that every technology is good enough for its own use case. I still don't understand why certain engineers don't get this and go from "XYZ is awesome, I use it everywhere" to "I'm over XYZ." Just like the title of the article suggests, GraphQL is great, but ONLY in the right context.
markhalonen 2y ago
I can say with 100% confidence that GraphQL via Postgraphile & TypeScript is a stellar tech stack for web applications beyond "hello world". If you are building on Postgraphile and raising from angels, dm me.
jensneuse 2y ago
Disclaimer, I'm one of the authors of an open source project to implement GraphQL Federation (https://github.com/wundergraph/cosmo https://github.com/wundergraph/cosmo). GraphQL, but more specifically GraphQL Federation solves an organisational problem. With Federation, teams can collaborate on building an API together with a Schema Registry and Composition Checks across all Subgraphs (Services), which is a unique enabler in the market. We've got a lot of customers in the enterprise segment and it's growing rapidly to the point where I'd say it's becoming an enterprise standard.
djcollier 2y ago
I have yet to find an alternative to the GraphQL protocol that has the following requirements: - Good support for HTTP 1.1 - Provides typesafe contracts for queries and mutations - Strong support for most common UI clients (JS/React Native/SwiftUI) - Backend can be written in a language that isn't JavaScript/TypeScript - Large developer community Closest thing I've found is defining your schema using OpenAPI spec, and using tools to generate code from that source for the client and server, but this is a much worse DX than the process of defining GraphQL schemas.

94 points by fagnerbrack 2y ago

I think that instead of addressing and correcting the original post the author validated and confirmed everything that was said in that original post.

fleshgrinder 2y ago
Glad I'm not the only one who feels that it's handwavy and full of excuses.
RedShift1 2y ago
I think you missed the point, most of the problems that affect GraphQL APIs you will also experience with REST APIs, or any kind of APIs.
AWebOfBrown 2y ago
I think that's demonstrably false. His point about the runtime complexity of an API being entirely distinct from how the interface to it's code is exposed (whether GraphQL or REST or otherwise) is fairly obvious, I think. The counter-argument is that unlimited query complexity makes it far bigger problem, and the author's point is that if you're using it for private APIs with persisted queries, you shouldn't have that problem unknowingly. Don't get me wrong - I think the takeaway is that GraphQL's niche is quite small, and he's defending exactly that niche. It's not often the case that you can develop an API in a private manner which doesn't undercut higher-order value in the future, as the rise of AWS hopefully made evident.

georgyo 2y ago

Wait, people are using graphql for private, not exposed, backend apis? Who would torture themselves like that? Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs? Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed. Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically. I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.

tossandthrow 2y ago
Pothos + graphql Zeus gives us the ability to expose a prisma like interface to the clients with the ability to curate what fields are exposed and maintain the ability to setup field level security. Oh, and we get DB schema to frontend propagation of changes to the type. This is by far the best experience I have had for private APIs - Where we don't need to maintain backwards compatability. I do get that the HN crowd is super adverse to graphql, but I fail to see other arguments than matters of taste.
- vosper 2y ago
  Would you consider this solution for a public (enterprise/B2B, not public-on-the-internet-for-anyone) API? I may need to build a public API that lets customers select certain fields from a variety of objects with many fields.
  - tossandthrow 2y ago
    Hmm, this is a really good questions and would definitely require a bit more information about the customer relation to fully answer. In a setup where you can deprecate fields and remove them after X weeks I think it could wor well - My impression is just not that enterprise works like that? I would probably go the route of having fully versioned APIs in the specific setup (GraphQl or not) - which is something that would be a hassle with a tight coupling between the Prisma schema and the GraphQl schema as proposed. Thinking about it, all the situations where I have successfully used GraphQL, there has been a relatively tight coupling between the database schema and the graphQl schema. Previously it has been Ecto + Absinthe + Zeus (Elixir on the backend).
    - vosper 2y ago
      Thank you for that. You’re right that there will need to be long-term support of API versions (or at least the current one and maybe the previous one). My instinct is to give the users the full objects and let them select the fields they want on their side. It’s less work on our side. Also I’m not sure about customer comfort with GraphQL.

lukevp 2y ago

The breaking changes part from the original article was clear to me. The author was saying that if you control the API and the client, it’s often quicker to release changes that are not backwards compatible as long as you can coordinate the release of the two. Then there’s no need to version at all. Sounds like this is harder with graphql than REST.

nesarkvechnep 2y ago
You probably mean JSON over HTTP when saying REST but the original idea of REST is painless evolution. No vX in the URL.
rbalicki 2y ago
Certainly, if you can either force your clients to refresh their browsers or can tolerate clients breaking, that works! That might work great for internal tools, for example (as long as no work is lost when you refresh, or you can just expect your employees to redo the work). But it’s not tenable for anything that customers use.

loveparade 2y ago

Eight Years of GraphQL, and I have yet to find a single use case for it in my projects. I've had to interact with external GraphQL APIs a few times and each time it has been a terribly painful experience. Funnily enough, for the few queries where GraphQL would've actually been useful to get some deeply nested data structure, it was usually impossible to use it because the "query is too big/deep" or it had cycles

PUSH_AX 2y ago
Are any of your APIs used by multiple consumers? This was the strongest use case I found personally.

robbyiq999 2y ago

GrahpQL was something that came up heavily in Front-End job ads and maybe even mentioned during my experience interviewing around 2017-2020 I was once even turned down for not having enough "GraphQL Experience" - Whatever that was. This was during a particularly painful 6 month rut for me - job search wise. It's absolutely infuriating that the tide has now changed. GraphQL doesn't matter. Did it ever? What was the point?

treve 2y ago
Web development goes through annoying hype cycles. GraphQL has great use-cases but it was overvalued. Unfortunately even if you recognize it you can't always avoid it if you want to be competitive in the market. Cynicism can be a trap with this stuff because it may just make you less hireable.
- ecjhdnc2025 2y ago
  I personally think GraphQL delivered on quite a lot of its hype, and I have become a bit more forgiving of web dev hype cycles in the light of crypto, NFT and generative-BS hype cycles...
  - treve 2y ago
    In my opinion the GraphQL 'wake up call' (if we can call it that) has less to do with its intrinsic value. With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad. However I think we've seen a lot of 'GraphQL as the default paradigm from the get-go', which I think is a trap and has caused a fair bit of pain for all the small startups out there that were sold on this.
    - megadal 2y ago
      > With the right team, with the right use-case it's excellent. So please don't take it as GraphQL=bad. If a framework requires you to be just as, if not more competent in its niches to achieve the same end you could've achieved without it, I think that makes it bad. That's like if an HTTP framework could only be effective at the protocol level with a team competent in HTTP. The whole point of a framework is abstraction. I have never once seen how GraphQL (the language) provides any sort of abstraction that the general framework itself doesn't, and the little abstraction GraphQL the framework does provide you can mostly sum up by just generating an OpenAPI over a set of schemas, with a whole host of benefits and few trade offs (on the implementation side, which is where your 10x devs usually live anyways). It's weird. It's like the main benefit of GraphQL is that there are groups of developers who understand it, but the biggest drawback is that it is needlessly complex, which again, seems to indicate GraphQL is bad. It's an abstraction that creates needless complexity (that you necessarily can't reverse because it's apart of the spec..)

chx 2y ago

I never understood the point. Really don't. GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response. If you are already built those then might as well just include the data necessary and use a REST API.

ecjhdnc2025 2y ago
It depends on whether your chosen platform can do it. If you're coding resolvers by hand, that is not fun. But for example the Lighthouse GraphQL layer for Laravel (it's a schema-first thing based on the Webonyx PHP GraphQL reference implementation) can do a lot of this for you using schema decorations. https://lighthouse-php.com https://lighthouse-php.com It has where/filter/sort/pagination, automatic scope narrowing etc., and you have very little code (if any) beyond the graphql schema to set it up. It integrates brilliantly with the Eloquent query builder. One of the best applications for PHP IMO; it is really enormously productive.
cheema33 2y ago
> GraphQL does not provide any built-in mechanisms for filtering, sorting, pagination or other arbitrary transformations of the response. GraphQL is just the protocol. It is up to implementations to add support for it. We use Hot Chocolate GraphQL server with entity framework backend, and it has built-in support for all of those things. Vast majority of the criticism of GraphQL comes from people who do not understand it. GraphQL does have a steep learning curve.

est 2y ago

GraphQL is painful. I am thinking some SQL but with more access control would be better.

resonious 2y ago
Completely agree. Most GraphQL interfaces are papered over a relational database that speaks SQL. It seems ridiculous to me to have 2 query languages on top of one another like this. Feels like any GraphQL system could've just exposed their SQL directly for way less code and more flexibility. Though I guess the layer in between lets you change your SQL schema without changing the GraphQL schema.
- noisem4ker 2y ago
  > the layer in between lets you change your SQL schema SQL has got views for that.

elmigranto 2y ago

So if most of the issues with GraphQL are the same as with the other approach, what is the point of GraphQL that justifies all the complexity?

rbalicki 2y ago
Fragment composition. See my comment here https://news.ycombinator.com/item?id=40984066 https://news.ycombinator.com/item?id=40984066

bcherny 2y ago

A lot of people in this thread are criticizing GraphQL. The reality is that GraphQL is a great tool for one job: building APIs that scale across thousands of engineers, billions of users, and many megawatts of machines. This is what we use GraphQL for at Meta. To make it work well, it takes dedicated teams building infrastructure that makes the DevX great. It takes many years to build this out across various backends, clients, and internal tools. We have open sourced some of this infra — the GraphQL spec, Relay, GraphiQL, etc. But there are many tools we built that we have not open sourced yet, largely because they’re tightly coupled to our internal ORMs, runtimes, error handling, authentication and security systems, and so on. I wish we open sourced more of our GraphQL stack, so more people could experience the awesome DevX we have internally. At the same time, GraphQL is a tool. No tool can be used all the time for everything. Meta’s 3rd party APIs still use REST for this reason; some internal services use Thrift; etc. It’s up to you to evaluate the tools available to build the way that makes sense for your business. Because some parts are available off the shelf, but others often need to be built in house, it is up to you to understand that cost and evaluate whether it is worth it for your use cases. My hope is that as time goes on, more dev tools startups come in the fill the gap in tooling around client libraries, auth, security, and so on to make GraphQL a good choice at smaller scales, too. The DevX is that good when you get it right.

cheema33 2y ago
GraphQL is particularly useful for data intensive applications. That is what we use it for. I frequently see people try to use it for simpler applications and give up quickly because it does have a steep learning curve, if you are trying to do it right both on server and client.

vlugovsky 2y ago

One of the useful things I learned from a professor at my university is that every technology is good enough for its own use case. I still don't understand why certain engineers don't get this and go from "XYZ is awesome, I use it everywhere" to "I'm over XYZ." Just like the title of the article suggests, GraphQL is great, but ONLY in the right context.

markhalonen 2y ago

I can say with 100% confidence that GraphQL via Postgraphile & TypeScript is a stellar tech stack for web applications beyond "hello world". If you are building on Postgraphile and raising from angels, dm me.

jensneuse 2y ago

Disclaimer, I'm one of the authors of an open source project to implement GraphQL Federation (https://github.com/wundergraph/cosmo https://github.com/wundergraph/cosmo). GraphQL, but more specifically GraphQL Federation solves an organisational problem. With Federation, teams can collaborate on building an API together with a Schema Registry and Composition Checks across all Subgraphs (Services), which is a unique enabler in the market. We've got a lot of customers in the enterprise segment and it's growing rapidly to the point where I'd say it's becoming an enterprise standard.

djcollier 2y ago

I have yet to find an alternative to the GraphQL protocol that has the following requirements: - Good support for HTTP 1.1 - Provides typesafe contracts for queries and mutations - Strong support for most common UI clients (JS/React Native/SwiftUI) - Backend can be written in a language that isn't JavaScript/TypeScript - Large developer community Closest thing I've found is defining your schema using OpenAPI spec, and using tools to generate code from that source for the client and server, but this is a much worse DX than the process of defining GraphQL schemas.