DEV Community

loading...
Cover image for Why GraphQL?

Why GraphQL?

saransh kataria on June 04, 2020

Originally published at https://www.wisdomgeek.com on June 2, 2020. Developing APIs for the web has never been an easy task for developers. REST h...
Collapse
bkis profile image
bkis

That's a pretty toxic way of responding to someone else's work. Don't take that as an offense but as a well meant personal advice: If you don't want other people to really hate working with you, change your communication!

BTW @saranshk Thanks for the article! I recently witnessed a pretty emotional argument about the pros and cons of REST and GraphQL and oh boy it could have used some objective insights like the ones you gave, here :)

Collapse
saranshk profile image
saransh kataria Author

Thanks for the kind words @bkis :)

Collapse
itsjzt profile image
Saurabh Sharma • Edited

For me the most important reson of using GraphQL is:
One models get big enough, overfetching and underfetching is a real issue

Collapse
patarapolw profile image
Pacharapol Withayasakpunt • Edited

I don't really get why you cannot expose req.query.fields or req.body.fields in a REST API. I think OData is doing that.

Also, this idea integrates well with MongoDB projection.

Also, I don't know how much idempotency matters in GraphQL. (e.g. GET vs POST)

Collapse
lifelongthinker profile image
Sebastian

Is idempotency an issue at all given that GraphQL only queries (reads) data? Or am I missing something here?

Thread Thread
radkin profile image
Noel Miller

It has mutations , similar to a POST in old school REST only capable of dynamically handling a subset of the data you CAN post.

Thread Thread
lifelongthinker profile image
Sebastian

Thanks, I didn't know that. The "Query" in QL to me suggested otherwise.

Collapse
saranshk profile image
saransh kataria Author

This post might be helpful in understanding the differences: jeffhandley.com/2018-09-13/graphql...

Thread Thread
patarapolw profile image
Pacharapol Withayasakpunt

Too long, many links, more of the complaints and telling that the writer is trustworthy; so I still understand nothing.

Not to mention that GraphQL can also be DoS and injected as well.

Collapse
greenroommate profile image
Haris Secic • Edited

Yeah, the "faster" argument is incorrect in my cases, and usually it's quite the opposite as a lot of transformations need to happen and on the other hand I can enforce specific stuff upon REST. Now getting less data might be faster for network but still slower to fetch from DB due to complexity of generating queries. Anyways depends on use cases, but the fact that I wish I could deliver both at the same time is coming from smartphone app team asking for this, and frontend constantly asking for that and wanting a way to fetch more stuff at once as they dislike 2 calls. However we benefit more from REST right now until we have more backend devs to provide both solutions

Collapse
daltonrooney profile image
Dalton

It shouldn’t be too hard to add caching for query results in the back-end, which does speed things up a lot. My CMS does this by default. (Craft CMS)

I haven’t noticed a significant performance penalty switching from REST to GraphQL, but maybe I’m just working on more simple apps. Performance totally depends on context here.

Thread Thread
greenroommate profile image
Haris Secic

I have a plan to expand up to at least 6 services and 3 of those should be like "core" or something. Now having 1 gateway joining them it means all 3 will work in parallel but still a lot of network calls so 1 monolith is much faster in that case, and regarding the use case, REST is faster as I just respond to URL request instead of mutating stuff; since I'm using specific structure mutating would require building a lot of queries differently and more code and more checks than one might use with straight forward approach like just to apply some library on top of it. I dislike caching so not a way for me.

But the main point is if you have specific type of requests and responses and use DTOs instead of domain models, customised queries, and specific security (not role based but user based - each user has it's own resources) then you hit this point. So it's quite boring and complex way to notice this but it happens way more often than one might think especially in big projects / companies. In the end resource based is easier as you don't care about fields and either user or gateway on top of it filter out stuff - well last one usually ends up being GraphQL as gateway joining REST services :D

Collapse
saranshk profile image
saransh kataria Author

There is a learning curve for queries and how it is structured on the server side, and it does require efforts on the backend code but as you said, it's good to fetch all of it in 1 call instead of 2 and that is what makes it faster because of the HTTP request response time.

Collapse
saranshk profile image
saransh kataria Author

It also is a good fit when supporting multiple clients that have different data requirements.

Collapse
itsjzt profile image
Saurabh Sharma

Yeah, agreed

Collapse
sam26880 profile image
Saumil Shah

I'm completely new to GraphQL but what do you guys think about the use case of publish-subscribe model and using GraphQL as a replacement for something like Firebase where you can send realtime data to clients who have subscribed. Or Am I not getting this right?

Collapse
saranshk profile image
saransh kataria Author

GraphQL subscriptions are probably what you are looking for. howtographql.com/graphql-js/7-subs... might be a good resource to get started.

Collapse
sam26880 profile image
Saumil Shah

@saransh kataria, thanks for the suggestion. I did know that's what I was looking for. I guess what I was trying to find out was people's opinion on it vs using something like Firebase. Any ideas?

Thread Thread
saranshk profile image
saransh kataria Author

It depends on your use case. I have used Firebase for a small application and it worked great, but it fell short on complex queries and did not have a sophisticated permissions system. I might be wrong since I did not use it a lot, but those two things made it a no go for bigger applications for me.

Thread Thread
sam26880 profile image
Saumil Shah

Makes sense. Thanks for the reply!

bkis profile image
bkis

Well, dude, thank you for proving my point.

Collapse
radkin profile image
Noel Miller

Nice post. My experience with interviews lately is that many companies are aware of the advantages of using graphQL (Apollo, et all), but they either don't have the know-how to add it or are locked into another approach.

Collapse
saranshk profile image
saransh kataria Author

When you say they don't know how to add it, you mean they know about GraphQL as a concept but have not implemented it? Could you elaborate a bit more on the specifics of that and being locked into an approach?

Collapse
radkin profile image
Noel Miller

Sure. Most tech interviewers have heard of GraphQL, that's universal. I have only talked to a handful that have a full blown implementation of Apollo Server/Client where they are using it in production. There are more that have a hybrid. E.G. old-school REST endpoints and limited Apollo Server while migrating to Client or perhaps only a few micro-services that use it.
The most likely by far is to speak with someone who says they want to use it and either they haven't tried it or someone tried to code it and either it was too much of a challenge or took too much time, etc. Granted, I haven't talked to "every" company in the Bay Area ... so, please take this with a grain of salt.
At my last company (thousands of developers) we had some people talking about it and testing something, but there was nothing in production. It was mostly a Java shop and their Server is not as Shiny as the JS implementation (or so I'm told)

Collapse
ozzythegiant profile image
Oziel Perez

GraphQL is one of those things that is shiny and everyone wants to use it, but most of the times it's overkill. I would say only use it for large models, models with dynamic data structures (think MongoDB), or for fetching data from multiple sources (APIs, databases, cache, files, etc.). Otherwise, stick to tried and tested simple REST APIs.

Collapse
turbopape profile image
Rafik Naccache • Edited

Isn't GraphQL tunneled through REST already ?
I think comparing GraphQL and REST as two different technologies is a bit misleading. One can't replace another, because one is simply a higher abstraction transported over another: GraphQL is a Data Oriented Querying language with complete end to end management - but it uses POSTs and GETs through HTTP - it's REST with good tooling on both sides and in between !
It's also important to understand that GraphQL is very powerful as a data tool, but it would be an overkill for pretty much anything else. I've seen people bending it to make it act as an authentication API !

Collapse
saranshk profile image
saransh kataria Author

There are a few things that are common, but there are a lot of differences as well. There can be a hybrid approach as well, or standalone implementations too. That is why mentioned about things REST can be good for, and GraphQL not being a silver bullet. And totally agreed about the data tooling part, that is what it does best, and only using it as an authentication API would be a poor use of GraphQL.

Collapse
daksamit profile image
Dominik Aksamit

The edge icon/logo in this article is outdated ;)

Collapse
saranshk profile image
Collapse
muneebjs profile image
Muneeb Khan

Excellent explanation!
Thanks for sharing.

Collapse
saranshk profile image
saransh kataria Author

Glad that it helped. Thanks for the appreciation.

Collapse
saranshk profile image
saransh kataria Author

Don't know what happened there, but put the bullet list back in there. As for grammar, could you point to instances? I don't see any of those and even Grammarly seems to agree.

Forem Open with the Forem app