DEV Community

loading...

Discussion on: 4 reasons why you should use GraphQL over REST APIs

Collapse
kfwerf profile image
Kenneth van der Werf

Thanks for the article.

I just wanted to mention that a lot of your benefits are based on implementation details in regard to specifically GraphQL. Over and under fetching is and can be an issue with GraphQL too, especially when it sits between the client and microservices. I don't really get your object definition point, i also think that might be an implementation detail you don't have to do. Could you expand on this? Caching can again be an implementation detail, REST can also fail to cache.

I think you are looking maybe too much from an implementation effort, i'm wondering what your thoughts are based on it from an solution oriented point of view? For instance the fact that GraphQL could be a good fit for many clients, or around versioning? I would love to hear your thoughts

Collapse
blessingartcreator profile image
Blessing Hirwa Author

Here are some use cases of GraphQL:

-Apps for devices such as mobile phones, smartwatches, and IoT devices, where bandwidth usage matters.

-Applications where nested data needs to be fetched in a single call.

-A composite pattern, where an application retrieves data from multiple, different storage APIs.

Collapse
kfwerf profile image
Kenneth van der Werf

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?

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

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.

Thread Thread
kfwerf profile image
Kenneth van der Werf

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?

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

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.

Thread Thread
andrewbridge profile image
Andrew Bridge

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?

Thread Thread
blessingartcreator profile image
Blessing Hirwa Author

REST can do it but Graphql uses low bandwidth compared to REST, that was my point.

Some comments have been hidden by the post's author - find out more