Isn't that the same as REST? Using that stops at the controller for the request, and then it's up to the sever how it wants to fulfill requests for entities.
The difference is that REST is more opinionated on the server for what gets returned, and how it is returned. With GraphQL, that power is in the client request. And allowing the client to dictate the full scope of data to be loaded on the server can cause some problems depending on how complex the data model is.
This is why we are going to surface the more complex children of certain models as root queries instead. It’s considerably less than ideal from an idiomatic GraphQL point of view, but it’s much more practical. If data models are simpler, then GraphQL works great. Or if the data model is flat, it works great. Anything else and it’s not as cut and dry.
It's less a criticism of GraphQL-the-specification and more a matter of GraphQL-the-community failing to provide any reference implementation for the most basic of usecases--the 95+% of apps that use ORMs.
That said, GraphQL-the-spec does highlight a key ORM weakness--it's not so easy to dynamically construct complex join queries with decently-optimized fetch plans.
