The n+1 would be there with REST too. Unless you have specific, optimized REST routes - but then you can do the same with specific, optimized graphQL queries too.
I feel your pain.
If you control the API and know all the use cases for a REST endpoint, the advantage is predictable performance characteristics and the tradeoff is flexibility.
It all depends on what you need (and maybe what tools you're using to mitigate GraphQL resolver problems).
You mean when someone creates a REST API he magically knows in advance how it will be used and writes a bunch of specific, optimized endpoints and queries such as "/magic-endpoint/" which returns 20 blogposts with their comments?
I don't think so. And even if that were true, the same could easily be done with GraphQL.
Where is the difference to GraphQL then? If you know in advance what will be queried then you can create an optimized query for it.
GraphQL allows ad-hoc queries of unlimited complexity and recursion
> If you know in advance what will be queried then you can create an optimized query for it.
No. In general you don't know what will be queried. And that's the reason why most GraphQL implementations end up using just a small predefined set of "persisted queries" (that is, REST with extra steps).
Persisted queries enter the game when you define a query that potentially can become very complex and deep and then want to restrict the complexity in specific ways. But that is not required if you just want to mirror a RESTful API.
I don't
> You can write very restricted queries that mirror REST routes 1:1. No need for persisted queries.
What stops a frontend developer writing an ad-hoc query?
> Persisted queries enter the game when you define a query that potentially can become very complex and deep
That... That is exactly what I wrote.
---
Honestly, I'm baffled at GraphQL defenders. It's like they never even read the documentation to the tools they defend.
- How is GraphQL different from REST?
- Ad-hoc queries of unlimited complexity
- But you write restricted queries
- No. The whole point of GraphQL is ad-hoc queries
- Persisted queries enter the game when you define a query that potentially can become very complex and deep
- That is exactly what I'm saying
And elsewhere, you can see it in other replies, it's the same story with N+1:
- GraphQL is great!
- Except the issues on the server and trying to handle N+1 queries
- What's N+1?
- It's.... It's a prominent part of the documentation for the frigging tool you use. And the reason for the things you advocate like dataloaders and persisted queries
What stops them is that the "ad-hoc" query can only look like this:
articlesWithComments($id) {
title
contents
comment {
author
text
}
}
article1: articlesWithComment(1) {
title
contents
comment {
author
text
}
}
article2: articlesWithComment(2) {
title
contents
comment {
author
text
}
}
It _is_ possible to allow a user to change the query like this:
articlesWithComments($id) {
title
contents
comment {
author {
name,
age,
articles {
...
}
}
text
}
}
What is "author" in that query and why can't the user do
author {
name,
age,
articles {
...
}
}
And what you're basically saying is: let's create REST with extra steps for no particular reason. With extremely complex setups where author in one query has a different set of fields than in a different query etc.
As for your question, why the user can't change the query (in this example) : because it violates the specifiction and will be rejected by the server.
Does it answer your questions?
What's the point of GraphQL in this case?
> https://news.ycombinator.com/item?id=25432655
In particular:
> Its much harder to make an efficient resolver than it is making an efficient REST endpoint.
As I showed, the claim is not true because it can be solved in the same way in both GraphQL and REST.
I've read the thread. And no, the context wasn't lost.
The whole point of GraphQL is flexible queries. And it is harder to make an efficient resolver in GraphQL than it is in REST.
And yes, your solution (and the solution everyone ends up arriving at) is reimplementing REST in GraphQL, poorly. Precisely because it is much harder to make an efficient resolver in GraphQL.