Imagine you're working on a bespoke blog engine for your company, so you have a GraphQL API that lets you query for all articles or just a single article.
Now the product folks want to add comments, so you add a new comments field on your article, with a new field resolver that queries the database for comments like SELECT * FROM comments WHERE article_id = ?.
This works great when viewing a single article: the frontend makes a single query to the GraphQL API, which makes 2 database queries: one for the article details and one for the comments
But then the product folks want to update the article search page with a expandable comment section for each article, so you can preview the comments for an article. Easy enough, all you have to do is add the comment field to the GraphQL query for the article search page, it's a GraphQL success story!
But now when the article search page loads, it runs 1 GraphQL query that retrieves 20 articles, and for each one it runs the SQL query to load comments. So instead of making 2 database queries it's 21.
Now we have performance scaling along with the number of results on the page, which is not ideal.
This problem exists in REST APIs in the exact same way though, unless you specifically optimize for this way of querying. But then you can do the same thing with GraphQL, so in the end GraphQL is not worse off, actually rather better because at least the problem exists only between backend and database, not between frontend and backend and database.
The idea is that there is a sort of contract between the backend and the frontend.
If I conscientiously create an API endpoint that allows you to fetch articles with their comments, I'm gonna craft that query to avoid the N+1 problem. So when someone uses it, perf isn't scaling linearly.
With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything. They say "yay it works, GraphQL is amazing", and nobody realizes this is causing scaling problems because nobody on backend actually thought about it.
> With GraphQL, you can have a frontend person add comments without anyone from the backend team modifying anything
Well, they can do that with REST as well. They will just make a bunch of requests. That is what usually happens in the real world.
However, the difference is that with REST, it all just looks like isolated independent requests. With graphQL it becomes more clear that someone wants to query all comments in just one query, so it's much more easy to detect and optimize for that case.
I don't know, I still think you're much more likely to have a frontend dev get annoyed by having to kick off 20 requests (and seeing that perf impact in their own devtools) and ask backend to give them an endpoint that can get all the content in one go.
Same. This is why I was looking for concrete examples because the problem isn’t a graphql problem, it exists in any interface. Kinda a trick question, but it was good reading people’s reasoning ;)
I agree with GP as well, but I do think there are unique circumstances with GraphQL.
One difference is that if the front-end makes N+1 REST calls, it's (hopefully) obvious to the front-end developer. It's also generally easy to map the REST requests to the database queries being made.
Swap it all out for a single GraphQL query and now you have no idea how it will perform or whether it was optimized for the specific fields you are requesting.
Another difference is that REST-style solutions won't work for GraphQL. Imagine you're making a bunch of REST calls, e.g. querying for a list of articles then querying for a list of comments for each one. You can ask the backend team for a new endpoint that returns them all in one query, easy enough.
But with GraphQL schemas, the potential graph of data is too large to write custom SQL queries that efficiently fetch everything in one batch. For example:
{
articles {
title
contents
author {
name
articles {
title
contents
comments {
content
author {
...
}
}
}
}
comments {
content
author {
name
}
}
}
}
Maybe a bit contrived, but it illustrates my point. Due to the ability to traverse relationships it's much easier to find yourself in a situation where the implementation of the GraphQL resolvers is not ideal for the usage, but it theoretically will work.
The solution for this is to use something like dataloader btw. It essentially waits for all these queries (I believe it uses queueMicrotask under the hood) and batches them. Not unlike other db batching proxies.
If that’s a problem, have the frontend run a separate query for the article’s comments upon expansion of the section, like the REST version would have done. You still have easier caching in the GQL version.
Use something like Postgraphile to create your graphql endpoint and it will issue a single query then massage the results into what it needs them to be.
Now the product folks want to add comments, so you add a new comments field on your article, with a new field resolver that queries the database for comments like SELECT * FROM comments WHERE article_id = ?.
This works great when viewing a single article: the frontend makes a single query to the GraphQL API, which makes 2 database queries: one for the article details and one for the comments
But then the product folks want to update the article search page with a expandable comment section for each article, so you can preview the comments for an article. Easy enough, all you have to do is add the comment field to the GraphQL query for the article search page, it's a GraphQL success story!
But now when the article search page loads, it runs 1 GraphQL query that retrieves 20 articles, and for each one it runs the SQL query to load comments. So instead of making 2 database queries it's 21.
Now we have performance scaling along with the number of results on the page, which is not ideal.