Not saying this has to exactly replace graphqL, but I'm struggling to understand the advantages and disadvantages over REST and GraphQL, or even how it tackles the problems graphQL is trying to solve.
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.
> 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).
> 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.
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.
One thing I do see that's missing (or maybe just not documented) is the power to specify the exact shape of the response.
One of the power of GraphQl is allowing us to specify how much or how little of the result objects we want. For example, a Blog post on a mobile app might just want only the short synopsis of the comments and the poster's name, while a web view might want the whole comment.
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.