| GraphQL doesn't allow for recursive types. This limitation cropped up in a project and was a frustrating (re)discovery. You have to pick a maximum depth and explicitly define that depth. It abuses POST. No way to tell by a quick glance at the network tab the purpose of a request. Whichever team controls the implementation of the resolvers decides the return structure which may be less than ideal for the front end team consuming the gql response so a good bit of additional mapping over the response is often necessary. GQL types are yet another type system I have to learn. I'm happy to, but compared to TypeScript, the GQL type system feels very lacking. To be fair, most type systems feel lacking compared to the TypeScript type system (its so insanely flexible and expressive). It's very easy to get to a point of a GQL query that makes so many sub queries that the single request takes a long time. Overall lots of foot guns. I much prefer a REST api and best yet an SDK. Others have also pointed out GQL can't take advantage of browser caches which is a big UX loss. I never got the hype around it but others like it so I'm glad it exists for them. |
It does, this schema works:
GraphQL queries describe the shape of the response, so with this schema it's not possible to ask recursively for "the full tree up to an arbitrary depth". One way to solve this would be to add a "descendants" field that returns a list of all the children, grand-children...