dlai

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.

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.

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.

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.

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 code example is it turns a rest call into a services layer then maps it to GraphQL.

I think this creates a bad convention of creating a service layer dependency on express where it's not needed.

As a proof, I like the idea, but in design I don't like adding extra coupling where it's not needed.