DEV Community

GraphQL vs REST - Conclusion

tbaveja on June 28, 2021

Often developers tend to feel a constant pull from REST while using GraphQL and vice-versa because of their similarities and functionalities, throu...

Read full post

Gordon Forsythe • Jun 30 '21

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.

leob • Jul 2 '21

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!

tbaveja • Jun 30 '21

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

NullVoxPopuli • Jul 1 '21 • 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?

tbaveja • Jul 1 '21 • 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 :)

mini kothari • Jun 29 '21

Very informative

tbaveja • Jun 29 '21

Thank You :)

Omri Ratson • Jul 3 '21

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

Arvind Padmanabhan • Jul 1 '21

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

tbaveja • Jul 1 '21

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 ☺️

Arvind Padmanabhan • Jul 1 '21

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

tbaveja • Jul 1 '21

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

Sean . • Jun 29 '21

Nice article, I enjoyed it quite a bit!

tbaveja • Jun 29 '21 • 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 :)

Sean . • Jun 29 '21

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

tbaveja • Jun 29 '21

Thanks. will share the link here :)

sefrem • Jul 3 '21

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

tbaveja • Jul 5 '21

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