> 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 a frontend developer writing an ad-hoc query?
What stops them is that the "ad-hoc" query can only look like this:
articlesWithComments($id) {
title
contents
comment {
author
text
}
}
That's all. Now the only way to change this query is to remove fields but there is no way to make anything more complex. The only way to do more is to repeat the query. I.e. literally:
article1: articlesWithComment(1) {
title
contents
comment {
author
text
}
}
article2: articlesWithComment(2) {
title
contents
comment {
author
text
}
}
That will create two queries in the backend - that is the equivalent of just making two requests against the same REST route.
It _is_ possible to allow a user to change the query like this:
articlesWithComments($id) {
title
contents
comment {
author {
name,
age,
articles {
...
}
}
text
}
}
But that is totally optional - you don't have to give your users this power.
> What stops them is that the "ad-hoc" query can only look like this:
What is "author" in that query and why can't the user do
author {
name,
age,
articles {
...
}
}
in that query?
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.
> I suggest you to take a step back and re-read the thread. Maybe the context got lost.
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.
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