Let's say you add a user object to your graphql. It's only so the viewer can inspect themselves (i.e. the current authenticated user). Maybe this is for a settings page or something.
A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection.
Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient!
Now every user can inspect all orders of every other user, if that user has left a review.
Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.
I am just pointing out that it is easy to make mistakes like this which would be, in this commenters experience, more obvious with a REST API.
In the equivalent REST API you would probably have to go far far out of your way to expose users order information in a reviews API, whereas in graphql that is the default.
In a typical REST application, it is enough to ask "does this user have permission to take this action".
In graphql, the question is rather different. It is "does this user have permission to access this data irrespective of the action they are taking", and you have to both ask that question and answer it correctly for everything in your graph.
If you go back to the early stuff coming out of Facebook about GraphQL, it was designed to roll up all the REST services (or similar) into a single request for high latency clients. Occupying what has become known as the backends for frontends (BFF) layer.
In theory, it should be just as obvious either way as your actual services are going to be REST (or similar) either way. I recognize that some people have started using it as a poor man's SQL, but that's not really what it is for.
In the wild, I primarily have seen graphql implemented instead of, or perhaps next to, REST. Not on top of REST.
I'm not sure what you mean about a poor man's SQL. Whether it's backed by micro-services via REST, or just a graphql API in a single app, the value prop for frontend<>backend communication is the same. It's not "using graphql wrong" to not have a micro service architecture.
>Now every user can inspect all orders of every other user, if that user has left a review.
Lmao that's just bad development, bad testing and the exact same thing can happen when using rest. "The dev wrote code and forgot to take permissions into account" happens to everyone.
And unlike rest, a properly written schema helps ensure they mostly do the right thing - even without strict permissions check, it should be obvious to anybody that they can't just write an `orders` resolver that does a `select * from orders`...
In practice, there are innumerable paths one can take through a complicated graph, and it is not reasonable or possible to test them all.
The cure is, like you say, writing a proper resolver. This form of permissions error most frequently happens when there is not a dedicated resolver (graphql-ruby, for example, makes it trivial to make a connection without a dedicated resolver).
I don't think this is as easy of a mistake to make with a typical REST application. In no normal universe would you return orders data in a reviews API, and the mistake would be much more obvious during development since you don't have to explicitly select the data you fetch from a rest API (so you are more likely to notice the extra information).
Whereas during development in graphql, the permissions error would be hidden because you probably would not select extra data for no reason.
A while later, suppose someone adds some connection from user to, say, orders. The person who added orders to users was kinda lazy and assumed (somewhat correctly, at that moment anyway) that permissions weren't an issue. So there's no additional permission checking when fetching the orders connection.
Now, suppose 6 months pass. Some other engineer is now implementing reviews. Each review must have an author. What do ya know, there's already a user object available in Graphql. How convenient!
Now every user can inspect all orders of every other user, if that user has left a review.
Mistakes like this are all too easy with graphql, and is the number one reason I would never consider using graphql without a query whitelist.