You Shouldn’t Use GraphQL(blog.logrocket.com)
blog.logrocket.com
You Shouldn’t Use GraphQL
https://blog.logrocket.com/why-you-shouldnt-use-graphql/
49 comments
> The turnaround was a minimum of three days and a new page could take weeks.
I think you finally convinced me that GraphQL does have a legitimate use case. Every time I evaluated building a GraphQL API, it had all of the complexity of the REST(ish) counterpart, and then some.
But where you put that complexity could have big impacts in a multi-team environment, particularly if it reduces round trips between teams.
This is basically my view on microservices as well (technical "solution" to an organizational issue), thanks for making me finally notice the parallel here!
I think you finally convinced me that GraphQL does have a legitimate use case. Every time I evaluated building a GraphQL API, it had all of the complexity of the REST(ish) counterpart, and then some.
But where you put that complexity could have big impacts in a multi-team environment, particularly if it reduces round trips between teams.
This is basically my view on microservices as well (technical "solution" to an organizational issue), thanks for making me finally notice the parallel here!
Agreed, I think I'm finally getting what it's for, and the grandparent post and this post made me want to try GraphQL actually!
It's interesting how now that it's explained this way, it's so hard to unsee it, yet it never even got close to clicking before.
Facebook was also running into issues where the API was diverging between iOS and Android based on their specific payload needs. Could either maintain two REST API's, or a single API that allowed each app to meet their needs without impacting release velocities.
A problem doesn't stop existing because you decided to ignore it.
GraphQL solves a very real problem. You need a way to sparsely grab information from multiple resources without having to make a dozen requests on the front-end.
Additionally, you need a standardized way to apply schemas to APIs. Also, you need a way to communicate to your clients how to interact with your API.
GraphQL solves these problems and more.
Comparing GraphQL to Rest is like comparing Rust to C and saying: "You don't need Rust. Memory safety isn't a realistic use case in the real world. Just allocate your memory and use it."
GraphQL solves a very real problem. You need a way to sparsely grab information from multiple resources without having to make a dozen requests on the front-end.
Additionally, you need a standardized way to apply schemas to APIs. Also, you need a way to communicate to your clients how to interact with your API.
GraphQL solves these problems and more.
Comparing GraphQL to Rest is like comparing Rust to C and saying: "You don't need Rust. Memory safety isn't a realistic use case in the real world. Just allocate your memory and use it."
That is not really a fair comparison. Rust adds on top of C. GraphQL adds but also removes a lot of nicest things about REST. http caching is the most obvious loss as well as any control access through a middle layer. You are also giving access to the user for a lot of power to make complicated and slow queries, against which protecting yourself is not always easy whereas having API quotas is trivial. A simple graphQL is easier and nicer to use than a easy REST, but as soon as it gets more than that you are trading facilities in the frontend against a huge headache in the backend.
One of my problems with GraphQL APIs is that the consumption of that API because really difficult for simple tasks. With a traditional API wrapper there will usually be a fetchResource() function that wraps the API call for getting a resource with function parameters mapping to HTTP query parameters usually.
With GraphQL I need to look up what specific query I need create to fetch a specific resource. It makes it harder to build quick, one off tools and scripts. Using GitHub's GraphQL API is what I specifically have in mind while I'm typing this.
With GraphQL I need to look up what specific query I need create to fetch a specific resource. It makes it harder to build quick, one off tools and scripts. Using GitHub's GraphQL API is what I specifically have in mind while I'm typing this.
I think the GitHub GraphQL API docs are particularly badly organized and basically show the API as a bucket of stuff, rather than as CRUD entities (which is how it's actually organized). I don't think this a GraphQL issue.
You have the exact same amount of work regardless of the two, which is reading the documentation. At least with GraphQLi, I can write a query with the docs open and iteratively explore.
Anecdotally, the experience is much easier when it's a REST API. If all I want is to fetch one object and its metadata... then I look up the function and call it.
If it's graphql then I have to... well, step one I have to learn the query language. And then I have to construct the query to return the data. It's not, like, super hard to go through all of that but it's extra cognitive burden that I don't want to deal with.
I'm currently writing CLI tools in Go and have to use the graphql API for github because it offers data that the REST API does not (I think). I really prefer the REST API wrapper.
If it's graphql then I have to... well, step one I have to learn the query language. And then I have to construct the query to return the data. It's not, like, super hard to go through all of that but it's extra cognitive burden that I don't want to deal with.
I'm currently writing CLI tools in Go and have to use the graphql API for github because it offers data that the REST API does not (I think). I really prefer the REST API wrapper.
> If all I want is to fetch one object and its metadata... then I look up the function and call it.
... it's literally the exact same thing for GraphQL. I open up GraphQL explorer, look at one root query I'm interested in, and fire off a request. It's really no different a workflow in Postman/Insomniac if I'm working with a GraphQL or REST API.
... it's literally the exact same thing for GraphQL. I open up GraphQL explorer, look at one root query I'm interested in, and fire off a request. It's really no different a workflow in Postman/Insomniac if I'm working with a GraphQL or REST API.
I am on my fourth rewrite on my in house web application. I am using ruby’s Sinatra with react as the front end. Including graphql in my front end and back end was easy. Querying the api was made easier with the “GraphiQL” app
The essay is not arguing that GraphQL does not solve a problem, but pointing out that it can be misapplied.
If you do not need to, as you say, "sparsely grab information from multiple resources", but have relatively fixed fetching needs, GraphQL is actually a bad fit. (The essay made this point slightly differently.) Additionally, there are other solutions to the schema problem.
If you do not need to, as you say, "sparsely grab information from multiple resources", but have relatively fixed fetching needs, GraphQL is actually a bad fit. (The essay made this point slightly differently.) Additionally, there are other solutions to the schema problem.
Oh very timely as I was just having this discussion with a friend recently.
With this article and articles like it, the author has an implicit bias toward “less is more” and “low level control is preferable”.
Yes in the unrealistic case that you are a lone developer working on a very simple app that never evolves then yes, graphql is overly complex. In the more realistic case that you’re working with a team of developers on an app that grows over time, things like schemas and standards and types become very useful, if not necessary for maintainability.
I’m not sure if there is a term for this (though the “no true Scotsman” cognitive bias comes to mind) but I do feel like there is a frustrating tendency for developers to tell other developers to cover the theoretical perfect thing over the practical great thing.
With this article and articles like it, the author has an implicit bias toward “less is more” and “low level control is preferable”.
Yes in the unrealistic case that you are a lone developer working on a very simple app that never evolves then yes, graphql is overly complex. In the more realistic case that you’re working with a team of developers on an app that grows over time, things like schemas and standards and types become very useful, if not necessary for maintainability.
I’m not sure if there is a term for this (though the “no true Scotsman” cognitive bias comes to mind) but I do feel like there is a frustrating tendency for developers to tell other developers to cover the theoretical perfect thing over the practical great thing.
Even then, after learning GraphQL I can’t imagine ever going back to REST with all the problems I know I’m bringing to the table.
Personally I think the mistake is to see it as a layer on top of HTTP, in any sense other than as a hack to make it work with web browsers (using POST /graphql as a poor man's plain old IP address or hostname).
In conceptual terms, it's clearly an alternative to HTTP, so it's not a surprise that it collapses all of HTTP's expressive power into the singularity that is POST /graphql.
It's interesting to imagine a web browser which truly did use GraphQL as a first-class query language comparable to SQL, with markup separated into another protocol altogether (HTTP GET, or an equivalent). I wonder what the future of web browsers looks like, and for how long we can continue simply by monkeypatching the HTTP resource model. Google's herculean efforts to adapt their crawler to the new de facto model, exemplified by SPAs, are interesting in what they reveal: https://static.googleusercontent.com/media/research.google.c...
In conceptual terms, it's clearly an alternative to HTTP, so it's not a surprise that it collapses all of HTTP's expressive power into the singularity that is POST /graphql.
It's interesting to imagine a web browser which truly did use GraphQL as a first-class query language comparable to SQL, with markup separated into another protocol altogether (HTTP GET, or an equivalent). I wonder what the future of web browsers looks like, and for how long we can continue simply by monkeypatching the HTTP resource model. Google's herculean efforts to adapt their crawler to the new de facto model, exemplified by SPAs, are interesting in what they reveal: https://static.googleusercontent.com/media/research.google.c...
The only term that immediately comes to mind is premature optimisation. Yes, there's an argument for minimizing the amount of redesign but I've found that by the time that's necessary I've discovered a dozen new ways of accomplishing the same task more efficiently anyway.
the only time i start out a new project with high throughput tools like graphql or Hadoop, etc is for a hobby when my ultimate goal is to learn a new technology.
the only time i start out a new project with high throughput tools like graphql or Hadoop, etc is for a hobby when my ultimate goal is to learn a new technology.
As with so many discussions around GraphQL vs REST, this is a category error.
Quoting Roy Fielding[1]:
> REST APIs must be hypertext-driven
> I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.
> What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?
There are certainly issues with GraphQL, not the least of which is security. (Facebook, I am told, generates a whitelist of allowed queries at build time. Do you?) But this article is discussing two different RPC implementations that have nothing to do with REST, properly understood.
That being said, I agree entirely that people should consider REST-ful system architectures, but within the context of hypermedia, rather than in term of JSON RPC.
[1] - https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
Quoting Roy Fielding[1]:
> REST APIs must be hypertext-driven
> I am getting frustrated by the number of people calling any HTTP-based interface a REST API. Today’s example is the SocialSite REST API. That is RPC. It screams RPC. There is so much coupling on display that it should be given an X rating.
> What needs to be done to make the REST architectural style clear on the notion that hypertext is a constraint? In other words, if the engine of application state (and hence the API) is not being driven by hypertext, then it cannot be RESTful and cannot be a REST API. Period. Is there some broken manual somewhere that needs to be fixed?
There are certainly issues with GraphQL, not the least of which is security. (Facebook, I am told, generates a whitelist of allowed queries at build time. Do you?) But this article is discussing two different RPC implementations that have nothing to do with REST, properly understood.
That being said, I agree entirely that people should consider REST-ful system architectures, but within the context of hypermedia, rather than in term of JSON RPC.
[1] - https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
Much of the reasoning specified is invalid with Relay. For example, you can lock queries from the client to predefined queries on the server.
While it may not be needed for your project, this is a downvote from me because I do think Graphql is a far superior means of querying than REST. I’ve personally dealt with cascading queries which make no sense, and declaring format on server, then constantly changing format ingestion on client, you might as well reinvent Graphql.
Some of the innovations Relay+Graphql have are very good including lazy querying with a tie-in to Suspense are very impressive.
While it may not be needed for your project, this is a downvote from me because I do think Graphql is a far superior means of querying than REST. I’ve personally dealt with cascading queries which make no sense, and declaring format on server, then constantly changing format ingestion on client, you might as well reinvent Graphql.
Some of the innovations Relay+Graphql have are very good including lazy querying with a tie-in to Suspense are very impressive.
I'm not a big fan of GraphQL, admittedly, but have used and understand it well enough and see where it shines.
What bothers me today is that so much usage seems to just be resume padding. Seems every time FAANG releases or talks about a tool that solves issues at their scale, everyone jumps to use it without thinking about whether it's necessary or even a good fit.
What bothers me today is that so much usage seems to just be resume padding. Seems every time FAANG releases or talks about a tool that solves issues at their scale, everyone jumps to use it without thinking about whether it's necessary or even a good fit.
I think of REST interfaces as being equivalent to a materialized view and GraphQL as being equivalent to an ad-hoc SQL query. The trade-off is performance and flexibility. GraphQL provides a great amount of flexibility, albeit with a cost to performance. A REST interface is able to provide high performance, but not nearly the amount of flexibility. Which tool you use depends on which factor is most important for your situation.
The actual title, and even more so the shortened version given here, are needlessly provocative IMO.
But the content itself is a little more thoughtful and tries to outline reasons why jumping on the GraphQL bandwagon might be a mistake.
I think there is a bit of bandwagon-jumping happening in fact with GraphQL, and articles like this can be helpful in helpful newcomers avoid some of the more major mistakes, because like everything else GraphQL can be seriously mis-used.
Useful to discuss anyway I reckon.
But the content itself is a little more thoughtful and tries to outline reasons why jumping on the GraphQL bandwagon might be a mistake.
I think there is a bit of bandwagon-jumping happening in fact with GraphQL, and articles like this can be helpful in helpful newcomers avoid some of the more major mistakes, because like everything else GraphQL can be seriously mis-used.
Useful to discuss anyway I reckon.
I honestly don’t see how every single con of graphql here doesn’t also apply to a poorly implemented REST service
This has been bothering me for years. I don't understand why REST vs GraphQL are so often presented as the only options. My observation is 90% of APIs for systems I've worked on should be using something more akin to RPC yet it doesn't even register in the conversation. I'm sure there are other great options too.
I've never seen an API on a project I've worked on that comes close to proper REST - and rightfully so as they'd never benefit.
I've never seen an API on a project I've worked on that comes close to proper REST - and rightfully so as they'd never benefit.
> My observation is 90% of APIs for systems I've worked on should be using something more akin to RPC
A lot of “REST” is something more akin to RPC, which is probably why those aren't broken out separately. REST only occasionally refers to anything resembling the architectural model described by Roy Fielding.
A lot of “REST” is something more akin to RPC, which is probably why those aren't broken out separately. REST only occasionally refers to anything resembling the architectural model described by Roy Fielding.
I don't know, I think gRPC is fairly common as well. Its not on the hype train because it doesn't move design control like GraphQL (which moved some API design control from backend to frontend devs.)
What I see wrong with GraphQL is that it makes the frontend lazier about thinking about what exactly it needs from the server. I'm talking about recurring queries. When you often need to update a tiny part of the UI, with GraphQL, it's much easier just to query the whole state again. Because you just reuse the same query, and also "just in case." It's not a tech issue, but how people tend to design an app with the technology.
The whole post shows the author hasn't fully understood what GraphQL actually is, and why it's used.
But this one:
> 6. REST is better for error handling and tooling
> Error handling in REST is easier when compared to GraphQL. RESTful APIs follow the HTTP spec with regards to resources and returns various HTTP statues for various API request states. GraphQL, on the other hand, returns the 200 Ok status for every API request, including for errors. This makes it difficult to manage errors and makes it hard to integrate with monitoring tools.
This is a misconception that seems to be quite hard to shake.
Yes graphql returns 200 OK even when there's errors inside the response. But thats not a bug, it goes to the design of the whole thing.
Think of graphql as a data transport layer.
Any HTTP code that indicates an error is likely unrelated to your query, and is usually handled somewhere else. For example if you get a 4xx response your auth token is probably expired.
Any errors in your query in a well designed schema can be seen inline.
Instead of having to chuck out the whole query and return a HTTP Status code.
GraphQL can also be sent over web sockets. HTTP means nothing to it.
This talk explains it way better than I just did, but note it's a really powerful feature.
https://www.youtube.com/watch?v=RDNTP66oY2o
But this one:
> 6. REST is better for error handling and tooling
> Error handling in REST is easier when compared to GraphQL. RESTful APIs follow the HTTP spec with regards to resources and returns various HTTP statues for various API request states. GraphQL, on the other hand, returns the 200 Ok status for every API request, including for errors. This makes it difficult to manage errors and makes it hard to integrate with monitoring tools.
This is a misconception that seems to be quite hard to shake.
Yes graphql returns 200 OK even when there's errors inside the response. But thats not a bug, it goes to the design of the whole thing.
Think of graphql as a data transport layer.
Any HTTP code that indicates an error is likely unrelated to your query, and is usually handled somewhere else. For example if you get a 4xx response your auth token is probably expired.
Any errors in your query in a well designed schema can be seen inline.
type Me {
name: String
email: String | AccessDeniedError
}
Instead of having to chuck out the whole query and return a HTTP Status code.
GraphQL can also be sent over web sockets. HTTP means nothing to it.
This talk explains it way better than I just did, but note it's a really powerful feature.
https://www.youtube.com/watch?v=RDNTP66oY2o
Point 1, exposing a potential denial of service attack via expensive queries, was always a point of contention I had with GraphQL. I'd love to explore using GraphQL in a project but security is typically a high priority. What is the generally accepted way of preventing denial of service attacks using oversized GraphQL queries?
one popular option is to have a query whitelist, with arbitrary queries allowed either through special permissions, or just in development. setting up CI steps to auto-publish any queries used by your apps is usually pretty straight forward. this obviously only works for non-public APIs.
Another common patter is to have a way to calculate query complexity, where each field had some cost, and some multiplier for list fields so you can calculate an approximate complexity before executing a query
Another common patter is to have a way to calculate query complexity, where each field had some cost, and some multiplier for list fields so you can calculate an approximate complexity before executing a query
FTA, though the misspellings are frustrating:
In a GraphQL API, tools such as Dataloader allow you to batch and cache database calls. But in some cases, even this [isn't] enough and the only solution is to block queries by calculating a maximum execution cost or query [depth]. And any of these solutions will depend on the library you’re using.
In a GraphQL API, tools such as Dataloader allow you to batch and cache database calls. But in some cases, even this [isn't] enough and the only solution is to block queries by calculating a maximum execution cost or query [depth]. And any of these solutions will depend on the library you’re using.
> Whereas, in a REST architecture, the client makes an HTTP request and data is sent as HTTP response, in GraphQL, the client request data with queries.
Already this isn't quite right.
Both (often) operate on HTTP (though of course other protocols could likely be used as well).
The difference lies in the idea, behavior, and ergonomics behind each. A frontend makes an HTTP request to a backend with a query and the back end fetches and returns the data as an HTTP response.
You can easily make a REST API that behaves like a graphql api through query parameters. GraphQL is a way of abstracting over multiple APIs, databases, etc and lets frontends get data without having to ask back end developers to change request handlers.
Already this isn't quite right.
Both (often) operate on HTTP (though of course other protocols could likely be used as well).
The difference lies in the idea, behavior, and ergonomics behind each. A frontend makes an HTTP request to a backend with a query and the back end fetches and returns the data as an HTTP response.
You can easily make a REST API that behaves like a graphql api through query parameters. GraphQL is a way of abstracting over multiple APIs, databases, etc and lets frontends get data without having to ask back end developers to change request handlers.
> Whereas, in a REST architecture, the client makes an HTTP request and data is sent as HTTP response, in GraphQL, the client request data with queries.
So GraphQL isnt HTTP. check. /s
i dont like graphql but this article didnt start out good...
So GraphQL isnt HTTP. check. /s
i dont like graphql but this article didnt start out good...
GraphQL makes a lot more sense at the scale of a big company where every team rewrites the same AJAX endpoint logic to fetch the same set of core entities (except in delightfully subtly different ways). Having “the one true” representation of your User object or Business object, but having the flexibility to fetch subsets of fields is huge.
And having a smaller team plug their page-specific types into the graph and just provide the foreign keys and have it “just work” is great.
GraphQL for me solves more of an organizational challenge rather than a pure technical challenge.
And having a smaller team plug their page-specific types into the graph and just provide the foreign keys and have it “just work” is great.
GraphQL for me solves more of an organizational challenge rather than a pure technical challenge.
GraphQL has many benefits especially around speed of development but flexibility comes at a price too. Security hardly seems to come up in these discussions but should probably be front and center. GraphQL presents challenges around controlling access to sensitive data especially in complex datasets where query flaws rear their heads. DDos’ing yourself is also common. Then throw in inconsistent authorization checks, managing rate limits and introspection.
REST models everything as data transfers, or as creating/reading/updating/deleting resources.
This alone makes it a bad choice unless you are building a business-agnostic document store.
GraphQL on the other hand has mutations, which if designed properly can convey all of your business's semantics.
This alone makes it a bad choice unless you are building a business-agnostic document store.
GraphQL on the other hand has mutations, which if designed properly can convey all of your business's semantics.
You can model almost(?) everything with CRUD on nouns instead of verbs.
Its just not that hard once you get the hang of it and it often makes things easier to reason about when it comes to state storage.
Its just not that hard once you get the hang of it and it often makes things easier to reason about when it comes to state storage.
If you don't like c.r.u.d., you also might not like variables in programming languages.
How do you square that title with literally the first sentence?
"Is GraphQL bad? Certainly not; GraphQL is great if you want to work in a declarative style because it enables you to select only the information or operations you need."
"Is GraphQL bad? Certainly not; GraphQL is great if you want to work in a declarative style because it enables you to select only the information or operations you need."
It doesn’t have to be REST vs GraphQL. You can have both for the price of one. Have the REST api call the GraphQL resolvers and return with correct HTTP status.
Is there a cached version somewhere? Log rocket website is blocked so I can’t view it on phone.
@dang please correct the title to "Why you shouldn’t use GraphQL". OP (maybe intentionally) left out the "why", completely changing the actual message in the article.
Tl;Dr: it's explaining situations where graphql may not be appropriate, not explaining why all situations are inappropriate for graphql.
Edit: seems like there's a trend here https://news.ycombinator.com/item?id=27484990
Tl;Dr: it's explaining situations where graphql may not be appropriate, not explaining why all situations are inappropriate for graphql.
Edit: seems like there's a trend here https://news.ycombinator.com/item?id=27484990
From the HN Guidelines:
> If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
I can see it either way. "Why" in the title is often clickbaity... But this title is clickbaity either way.
> If the title contains a gratuitous number or number + adjective, we'd appreciate it if you'd crop it. E.g. translate "10 Ways To Do X" to "How To Do X," and "14 Amazing Ys" to "Ys." Exception: when the number is meaningful, e.g. "The 5 Platonic Solids."
> Otherwise please use the original title, unless it is misleading or linkbait; don't editorialize.
I can see it either way. "Why" in the title is often clickbaity... But this title is clickbaity either way.
The "why" is extremely meaningful here, and removing it changes the meaning and intent of the title entirely. In the guidelines example, it'd be like changing "10 Ways To Do X" to "Always do X" which is obviously wrong.
Should be "when", or maybe "where", then, no? The "why" is just clickbaitese.
Clickbaity garbage.
Yep, exactly. Usually we don't see content this poor make front page of HN.
Knew it as soon as I read this: "In a REST architecture, the client makes an HTTP request and data is sent as HTTP response, but in GraphQL, the client requests data with queries."
Knew it as soon as I read this: "In a REST architecture, the client makes an HTTP request and data is sent as HTTP response, but in GraphQL, the client requests data with queries."
yeah "vim vs emacs" for webdevs
Now the frontend gets almost all data through graphql, and happily write and update their own queries without the backend knowing or caring about it unless there's a question or bug or an extension needed to the api. They iteratively design queries with history and docs and autocomplete on graphiql. This is a huge time saver all around.
We could have wrapped our platform in rest apis instead, but compared to graphql it would be like a bookstore that sold paragraphs rather than books.