Hacker News Reader

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

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

> I'm struggling to understand the advantages and disadvantages over REST and GraphQL

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

[1]: https://www.graphiti.dev/guides/why

I appreciate the effort. I think it is a bit of initial information overload having to read through tons of theory before getting to examples, which is why I skimmed through it and went to the examples. However the examples, did provide too much explanation and at the surface looks like a Query ORM via URL. This seems like a nice idea for things within a single domain, such as a master/detail view.

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.

Hi Dlai - you'd be able to fetch it all, across all your microservices, without creating a new entity. Will try to improve our messaging, but this one might be up your alley https://www.graphiti.dev/guides/concepts/remote-resources

Hi dlai - you can do all this in Graphiti. The client can specify only the fields/associations it wants, you can grab everything in a single request, and than single request can fan across microservices. This video might help https://youtu.be/_QqXjZDzTf4

That video is definitely a great start. They should add that to the homepage. I was having a hard time comprehending all that in "Why Graphiti", that video explains it nicely.