Maybe the lesson here isn't that GraphQL is a magic bullet, but that designing your API for your business needs solves a lot of frontend complexity (even if it's not pure "REST").
This is the single biggest advantage of GraphQL and AFAIK one of the main reasons for it's conception.
Not saying that being pure to rest ideology is a good thing. I think it’s a terrible fit for most applications more complex than a demo todo app
"The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on."
By the way, REST is not an ideology, it's an architectural style. It defines a set of constraints, and specifies the advantages and disadvantages of applying each of them.
So.... That's why you decide to create ad-hoch APIs using GraphQL queries instead: "the client can control the shape of the data it needs"