The last two bullets, why would you not do it with REST? Especially the last one im wondering what the benefit is of choosing GraphQL? Is it convience, because the data loaders are already there?
On the second last bullet about nested calls we can suppose that we blog or social networking platform where posts need to be fetched along with nested comments and details about the person commenting. You can also refer to the example provided in the article.
On the last bullet point we can suppose that we have a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, and third-party analytics tools to capture end-user interactions.
Not really sorry, the first can be done as well with REST, if you would include all that info in the request for the post right? or is that not very RESTy? The last bullet i also still don't completely understand. A backend using rest could still easily consolidate those services?
GraphQL allows multiple resource requests in a single query call, which saves time and bandwidth by reducing the number of network round trips to the server. It also helps to prevent waterfall network requests, where you need to resolve dependent resources on previous requests. For example, consider a blog’s homepage where you need to display multiple widgets, such as recent posts, the most popular posts, categories, and featured posts. With REST architecture, displaying these would take at least five requests, while a similar scenario using GraphQL requires just a single GraphQL request.
If you put all of the requests in one API then you'll to write many lines of code compared to GraphQL and it'll increase execution time. The goal here is to make things simple and fast.
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.
The last two bullets, why would you not do it with REST? Especially the last one im wondering what the benefit is of choosing GraphQL? Is it convience, because the data loaders are already there?
On the second last bullet about nested calls we can suppose that we blog or social networking platform where posts need to be fetched along with nested comments and details about the person commenting. You can also refer to the example provided in the article.
On the last bullet point we can suppose that we have a dashboard that fetches data from multiple sources such as logging services, backends for consumption stats, and third-party analytics tools to capture end-user interactions.
Hope this answers your question.
Not really sorry, the first can be done as well with REST, if you would include all that info in the request for the post right? or is that not very RESTy? The last bullet i also still don't completely understand. A backend using rest could still easily consolidate those services?
GraphQL allows multiple resource requests in a single query call, which saves time and bandwidth by reducing the number of network round trips to the server. It also helps to prevent waterfall network requests, where you need to resolve dependent resources on previous requests. For example, consider a blog’s homepage where you need to display multiple widgets, such as recent posts, the most popular posts, categories, and featured posts. With REST architecture, displaying these would take at least five requests, while a similar scenario using GraphQL requires just a single GraphQL request.
If you put all of the requests in one
APIthen you'll to write many lines of code compared toGraphQLand it'll increase execution time. The goal here is to make thingssimple and fast.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.