[pas]

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

[shhsshs]

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

[intellisense]

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

[kalcode]

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.

[intellisense]

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.