JSON:API solves this problem through sparse fieldsets[1]. Graphiti clarifies the spec by allowing sparse fieldsets at any level of nesting. As the original author and a current editor of the spec, I think we should adopt this extension into the spec proper.
> * pooling requests to multiple domains into a single request
JSON:API operates against a logical "graph in the sky", just like GraphQL. Graphiti makes it possible to mix and match database queries with other services and even plain Ruby objects[2].
One nice thing about this approach is that you still get to make database queries that take advantage of indexes and other database optimizations organically and by default. GraphQL's field-based approach can often result in a lot of extraneous database queries in the service of a homogenous server API that is based on fields.
(In my experience working with GraphQL APIs, I've seen a lot of performance issues that could only be debugged as "why is this field slow" that could have benefited a lot from making a big chunk of the query against a SQL database, directly using decades of optimizations around query planning).
[1]: https://jsonapi.org/format/#fetching-sparse-fieldsets [2]: https://www.graphiti.dev/cookbooks/without-activerecord
The "Why Graphiti" page[1] goes into some of this, getting into some comparisons of REST, RPC, and GraphQL, as well as discussing the conventions that make some of Graphiti's approach possible.
Disclosure: I'm the other author of Graphiti
In my reservations example, if I wanted to get availability, pricing, and content from 3 separate domains in a microservice environment, using this paradigm, I think I still would have to create a 4th endpoint that that combines the 3 in a separate entity called VacationPackages if I wanted to keep separation of concerns.
Otherwise, it might be calling a CMS endpoint, which has an include of availability endpoint, which has a nested include of the pricing endpoint.
My understanding looking at the query examples, https://www.graphiti.dev/quickstart#querying
It looks more like an ORM querying over rest than it is graphQL. It doesn't appear to solve some or the 2 major headaches graphQL is great at solving: * clients choosing how much data they need. On a desktop on broadband client, I want details of a list of entities, while on a mobile app with limited screen space and less bandwidth, I just need the skinny details like title and summary. * pooling requests to multiple domains into a single request. For example, if I writing a reservations endpoint, for purchasing flights. I need to call 3 separate microservices, 1 for availability and booking, 1 for ecommerce that's hooked up to an accounting system, and one for trip details from say a CMS system. I don't see how this saves the client the burden of making all these separate requests. In rest, you probably will have 1 endpoint that combines these requests, and separate endpoints for accessing this information individually. GraphQL saves the burden of maintaining separate combination endpoints.