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...
For further actions, you may consider blocking this person and/or reporting abuse
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 :)
Thanks for the kind words @bkis :)
It has mutations , similar to a POST in old school REST only capable of dynamically handling a subset of the data you CAN post.
For me the most important reson of using GraphQL is:
One models get big enough, overfetching and underfetching is a real issue
I don't really get why you cannot expose
req.query.fieldsorreq.body.fieldsin 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)
This post might be helpful in understanding the differences: jeffhandley.com/2018-09-13/graphql...
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.
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
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.
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
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.
It also is a good fit when supporting multiple clients that have different data requirements.
Yeah, agreed
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?
GraphQL subscriptions are probably what you are looking for. howtographql.com/graphql-js/7-subs... might be a good resource to get started.
@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?
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.
Makes sense. Thanks for the reply!
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.
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?
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)
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 !
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.
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.
Well, dude, thank you for proving my point.
The edge icon/logo in this article is outdated ;)
Haha, good eye.
Excellent explanation!
Thanks for sharing.
Glad that it helped. Thanks for the appreciation.
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.