I understand that this is always touted as a big plus of GraphQL, but it's absolutely possible to do this with a REST API, check out the spec for JSON:API, which allows nested entity relationships to be defined as part of a single request.
That aside, if you have control over the API you're querying, there's no reason you can't define an endpoint that includes all the data you need in a single request anyway, right?
I think the parent comment might be asking why using GraphQL instead of REST would result in fetching less data. There's nothing about a REST API specifically that means more data would be sent than with a GraphQL API. Only a poorly designed REST API that sends huge amounts of data unnecessarily would have this issue.
All GraphQL does is move the problem to the frontend, now it's up to a frontend developer, rather than the API developer, to determine how much data is needed. Meanwhile, the API developer also has to ensure that any possible combination of data structure can be efficiently returned from the API rather than preset structures which can be optimised and cached.
With that said, if you're building a data heavy system, where the user of the frontend has lots of interactivity, GraphQL could make requests more efficient by only requesting the data the user has asked for. Data heavy tables and large, interactive charts could certainly see a bandwidth benefit. But with that benefit, you lose the ability to cache responses (meaning you could end up fetching more data overall) and gain an additional performance overhead on the server.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I understand that this is always touted as a big plus of GraphQL, but it's absolutely possible to do this with a REST API, check out the spec for JSON:API, which allows nested entity relationships to be defined as part of a single request.
That aside, if you have control over the API you're querying, there's no reason you can't define an endpoint that includes all the data you need in a single request anyway, right?
REST can do it but Graphql uses low bandwidth compared to REST, that was my point.
I have no idea how can GraphQL possibly do this with lower bandwidth. It sounds exactly the same to me regardless of which way you fetch data
The reason behind this is that when you fetch few data then the bandwidth will decrease as there will be a few data to download.
I think the parent comment might be asking why using GraphQL instead of REST would result in fetching less data. There's nothing about a REST API specifically that means more data would be sent than with a GraphQL API. Only a poorly designed REST API that sends huge amounts of data unnecessarily would have this issue.
All GraphQL does is move the problem to the frontend, now it's up to a frontend developer, rather than the API developer, to determine how much data is needed. Meanwhile, the API developer also has to ensure that any possible combination of data structure can be efficiently returned from the API rather than preset structures which can be optimised and cached.
With that said, if you're building a data heavy system, where the user of the frontend has lots of interactivity, GraphQL could make requests more efficient by only requesting the data the user has asked for. Data heavy tables and large, interactive charts could certainly see a bandwidth benefit. But with that benefit, you lose the ability to cache responses (meaning you could end up fetching more data overall) and gain an additional performance overhead on the server.