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
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 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
For me the most important reson of using GraphQL is:
One models get big enough, overfetching and underfetching is a real issue
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
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 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
It also is a good fit when supporting multiple clients that have different data requirements.
Yeah, agreed
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.