loading...
re: 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 oth...
 

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

code of conduct - report abuse