>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.
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`...