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