DEV Community

loading...
Cover image for GraphQL vs REST -  Conclusion

GraphQL vs REST - Conclusion

tbaveja
MERN Stack Developer
・3 min read

Often developers tend to feel a constant pull from REST while using GraphQL and vice-versa because of their similarities and functionalities, through this article I hope to help you find the best fit for your app depending upon your use-case and tailor made requirements. Let's start !

If you're not aware of GraphQL, I would highly recommend you to checkout one of the below:

Similarities between GraphQL and REST

GraphQL and REST essentially accomplish the same task, i.e., communicate with a server and retrieve data. Here are a few similarities between the two:

  1. Both GraphQL and REST are based on the concept of a resource, and they specify IDs for those resources.
  2. Both GraphQL and REST rely on frameworks and libraries to handle the tiny networking details.
  3. Both can differentiate if an API request is intended to read data or write it.

Why GraphQL ?

1. One Unique Endpoint: GraphQL exposes a single endpoint that allows you to access multiple resources.

2. One request, Many resources: Query one or more resources in the same request. This will avoid making multiple API calls for an operation.

3. No Over Fetching or Under Fetching: The main advantage of GraphQl over REST is that REST responses contain too much data or sometimes not enough data, which creates the need for another request. GraphQL solves this problem by fetching only the exact and specific data in a single request.

4. Extending APIs: Adding functionality wouldn't affect existing client GraphQL queries.

5. Bandwidth: If your API is intended to be used on a mobile application or a large application like Facebook Newsfeed, use GraphQL since it offers better bandwidth usage.

Why REST over GraphQL ?

1. Handling complex queries: We have to specify everything we want to bring. “. If you’re not careful, a few big queries can bring your server down to its knees. In that sense, GraphQL’s greatest strength can also be its greatest weakness.”

2. Code vulnerability in GraphQL: If an attacker wants to carry out a DDoS (Denial-of-service-attack) to an unprotected server, all he has to do is execute an expensive nested query to overload your server.

3. HTTP Caching: REST allows data to be cacheable, which might improve performance and scalability whereas, GraphQL uses a single endpoint and custom requests, so caching is complicated.

4. Error Reporting: With REST, you can use API responses and build a monitoring system for error messages. But error reporting in GraphQL leaves a lot to be desired, with the ubiquitous “200 K Error — Something went wrong” message.

5. Data Formats: REST APIs support various data formats (XML, JSON, HTML, plain text, etc.) whereas, GraphQL only supports JSON.

6. Rate Limiting: Another problem with GraphQL is rate-limiting. In REST API, you can simply specify that we allow only this amount of requests in one day", but in GraphQL, it is difficult to specify this type of statement.

Conclusion:

If your API is intended to be used on a mobile application or a large application like Facebook Newsfeed, use GraphQL since it offers better bandwidth usage. Or, applications where we usually need nested data to be fetched. i.e. blog posts with their comments and people details.

If you need caching and monitoring facilities in your API, use REST. Or, public APIs where we want to determine what to expose to the clients.

You can also use a combination of GraphQL and REST for a project. It all depends on your data and performance requirements.

Must Read:

Always try to follow and learn from case studies. Below are the case studies from Netflix Tech Blog:

.

"Learn Together, Grow Together !"

.
That's It ! And don't forget to explore various tools available for GraphQL !
Cheers

Discussion (42)

Collapse
baohx profile image
Gordon Forsythe

Just want to mention the many built-on-rest protocols like Odata, HAL, HATEOS, JSON-LD, and JSON-API. Most of these take care of all of the arguments for graphql, while still remaining RESTful and utilizing all of the wonderful functionality provided by standard browser usage like caching. Odata especially is pretty awesome in my experience, and still allows you to request a very specific structure of data.

Collapse
leob profile image
leob

That's a great comment - people often think that it's a contest between simple & low-level REST on the one hand, and complex/sophisticated GraphQL on the other hand, but you're right to point out that it's not as black and white as that, and that there's a middle ground!

Collapse
tbaveja profile image
tbaveja Author

Thanks for reading the post !
I just googled these terms and found interesting. Thanks for sharing the knowledge, it will surely help :)

Collapse
nullvoxpopuli profile image
NullVoxPopuli • Edited

Rest and graphql shouldn't be comparable.
It's like comparing low level sockets to HTTP

Why not compare something more apples to apples like { json:api } and GraphQL?

Collapse
tbaveja profile image
tbaveja Author • Edited

Hey, I compared as both can communicate with a server and retrieve data and accomplish the same task as I mentioned in similarities.
Although, I like your POV of comparing graphql with { json:api } but most of the people are replacing REST with graphql in indsutry so I thought I should throw some light on graphql vs REST so that people can make better choice.
And, I would love to hear your experience on json:api :)

Anyways, thanks for reading the post and sharing your knowledge. It will surely help :)

Collapse
minikothari profile image
mini kothari

Very informative

Collapse
tbaveja profile image
tbaveja Author

Thank You :)

Collapse
omriyahoo profile image
Omri Ratson

In the "Why Rest" part you can eliminate points 1 and 2 by implementing key-values pair of the server for key - "name of the query" and in the server will be the value - "actual implementation of the query.
and only responed to this keys provided.
Of course you can provide paramaters so it's kinda of like calling a method on the server, you don't really care what's in the method, only the parameters and what the method returns.
You can validate as well the parameters to prevent overloading the server.
Hope it helps...

Collapse
arvindpdmn profile image
Arvind Padmanabhan

Good to know where REST might still be useful over GraphQL. Also see migrating from REST to GraphQL: devopedia.org/rest-api-to-graphql-...

Collapse
tbaveja profile image
tbaveja Author

Thanks for reading the post !
I saw the article and found interesting. Thanks for sharing your knowledge :)
Also I noticed you're founder of devopedia. It feels good when someone like you read and appreciate the post. Thanks ☺️

Collapse
arvindpdmn profile image
Arvind Padmanabhan

You can also write on Devopedia platform. Given your background, you can write an article on "MERN Stack"

Thread Thread
tbaveja profile image
tbaveja Author

Thanks. Yes, I will explore and try to write few on Devopedia as well :)

Collapse
seanb33 profile image
Sean .

Nice article, I enjoyed it quite a bit!

Collapse
tbaveja profile image
tbaveja Author • Edited

Thank You ! Glad to hear that. I am planning to write next blog on the implementation of same i.e. implementation in graphql vs REST. I hope you'll like that too...
Also, in case of any suggestion, I would love to hear that :)

Collapse
seanb33 profile image
Sean .

I will surely look forward to that too! keep up the great work

Thread Thread
tbaveja profile image
tbaveja Author

Thanks. will share the link here :)

Collapse
sefrem profile image
sefrem

In my experience there is single to no advantages in using Graphql over Rest on small to medium projects. In only brings complexity.

Collapse
tbaveja profile image
tbaveja Author

Oh okay, I am going to post a new blog on implementing the listed features in graphql vs REST in around 1 week. I will read more on the same. BTW, thanks for reading :-)

Collapse
diegoguevara profile image
Diego Guevara

I had the experience in a real project, in this project we use GraphQL only for html reports and REST for all other interactions

Collapse
tbaveja profile image
tbaveja Author

Thanks for reading and sharing your experience :-)

Collapse
reachsuman profile image
reachsuman

Very useful blog post, thanks for sharing it

Collapse
tbaveja profile image
tbaveja Author

You're welcome ! Thanks for reading :)

Collapse
alex_xu profile image
MrXujiang

very instesting

Collapse
tbaveja profile image
tbaveja Author

Thanks !

Collapse
nipun profile image
Nipun Sood

Very informative 👍

Collapse
tbaveja profile image
tbaveja Author

Thanks buddy !

Collapse
namanbansal profile image
Naman Bansal

Amazing! It was a one of the good reads!
Thanks for sharing this.

Collapse
tbaveja profile image
tbaveja Author

Thanks for reading bro !

Collapse
experiencenote profile image
ExperienceNote

Nice one👍

Collapse
tbaveja profile image
tbaveja Author

Thanks buddy :)

Collapse
tbaveja profile image
tbaveja Author

Thanks for reading the post and sharing your experience !
I started working on GraphQL few months back :)

Collapse
anmolchopra69 profile image
Anmol Chopra

Awesome !! Insightful for me.

Collapse
tbaveja profile image
tbaveja Author

Thanks buddy :)

Collapse
moyohussein_92 profile image
Hussein AbdulQohar

Very informative. Know your weaknesses and your strengths.

Collapse
tbaveja profile image
tbaveja Author

Thanks buddy !
Yes, I agree, only then you'll be able to make productive decisions for your project.

Collapse
djnitehawk profile image
Dĵ ΝιΓΞΗΛψΚ

personal opinion...
graphql = yuck
🤪

Collapse
tbaveja profile image
tbaveja Author

Hahaha, sometimes it is 😄
But sometimes GraphQL is the best fit 😝
Anyways, thanks for reading the post 😌

Collapse
vladi160 profile image
vladi160

The whole "why GraphQL" section is the same and for REST.

Collapse
tbaveja profile image
tbaveja Author

Same as in ?

Collapse
vladi160 profile image
vladi160

Same as in the REST API.

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