Isn't a big feature of GQL that it allows you to filter in the query, thus allowing the backend to fetch and render less data?

Also, which properties of GQL make it inherently slower than REST ... ? Both are abstract concepts. (Also I'd argue that GQL is REST.)

> Isn't a big feature of GQL that it allows you to filter in the query, thus allowing the backend to fetch and render less data?

That feature is not exclusive to GQL.

Agree but I believe the distinction is that in GraphQL this is part of specification to address overfetching/underfetching issues.

That is more related to the frontend, the frontend doesn't have to overfetch data.

But the graphql still will fetch that data and just filter what does out, it still has to get that data.

Example is a query like

``` { currentUser { id name todoLists { title items { name } } } } ```

The resolver will likely get the whole user object from the database, then just send name and id. Then when it finished getting the user, it will then query for the todo lists, and then only send the title (even though it got the whole row for each todo list), then after it fetches those lists, it will query for the items. And retrieve the whole rows of each item from the database.

The data the server needed to fetch didn't change, just what the frontend receives. It is still loading and fetching all the data on that query and then graphql filters the results leaving the server.

Also in the above steps, you notice it queries AGAIN after a data set has been retrieve, this causes an N+1 problem.

It is not inherent in the specs or implementation that fixes these. If you want to avoid fetching the whole object you will need custom code, and to avoid N+1 problem, you need batching of data within requests that "caches" or consolidate nested requests like data-loader, and some form of response caching to help with these issues.

Not siding against the tech, just clarifying those cons.

Yes the client queries for only data it needs and server returns only data which client requested.

With this query, { currentUser { id name todoLists { title items { name } } } }

It is up to the server how it is implemented.

- The server can fetch all the data for the user, todolist and items from the database in one go and resolve the client query mentioned above. In this case there will be overfetching from the database if the client only requested user information.

The server can also fetch the data in 3 queries

1> First to fetch the user, lets say with id 1. 2> Then get all the todos for the for user id 1. 3> Then get all the items for all the todos in step 2. Batching/Dataloaders.

All these queries can be executed in parallel on the server side. Does this make the server complex? Yes but there is also benefit to this when the user only request currentUser it does not fetch any todolists or items from the database.

I may be wrong about this, but here's how I see things: I think the two main "variables that depend on" performance are latency and how much computer power you need. And the "variable that depend on" how much computer power you need are server costs, and the architecture of your application.

If we assume that REST serves more requests than GraphQL, but GraphQL is more flexible, that may be a trade off of dev time of the application vs a dev time of the infrastructure. Which would fit with more and more people using orchestration and things like that. That might be a very wrong assumption though.

personally I found gql to have a steeper learning curve in that it adds an abstract layer to the stack. I call it an abstract layer, the author calls it a BFF (backend for the frontend).

As far as dev time excluding onboarding time, lets not forget why gql was created - facebook wanted to separate the data responses to their mobile and web platform

first of all, not all organizations are facebook

secondly, especially for smaller to medium sized startups, not all responses need to be separated, and "shaving" off data for an extra endpoint is not difficult in REST.

and I remember graphql's early website where they made the claim saying that you'll need to have some really huge number of endpoints in order to emulate what graphql has to offer, and since then they have taken that down because of how ridiculous that sounded.

In reality and practice, the number of endpoints that you need to "shave", again, especially for small to medium startups, is slim to none.

sure, I can accept that definition of latency. However, the author, when describing latency, only specified the distance traveled to justify a graphql server without implicating anything else.

In this comment you've made a claim that GQL is not only weaker than REST here, but notoriously weaker. The only argument that you seem to have made here is that a REST call "can" do the same type of things that are built into GraphQL.

You haven't supported your position that GraphQL is weaker at all. Everything that I have read, seen and heard is exactly the opposite. GraphQL seems to be the "I will never go back to REST" experience for virtually everybody I know in the field who has used it.

The other issue is that you're fighting the nature of REST itself to make it do more. Sure, you can make any API call take in specific input and send out exactly the output that you need...but REST API guidelines tend to preach exactly the opposite approach. The call should return one thing and if you want more, you need to get it yourself.

I'm open to hearing your perspective on this, but if you're going to make a claim like that you really need to support it.