Hi,
probably you guys are already sick from this topic... but I can't seem to find any answers when just using the web search. All I find are some intro tutorials and some high-level marketing comparisons between REST and GraphQL.
Some Background: I've been working in software development for about 15 years and mainly worked with REST webservices (as backend developer)... currently I'm working on my first project using GraphQL... and it's somewhat hard to see the benefits for me...
And it is not my goal to shit on GraphQL or something like that... but maybe get some insights where I maybe got something wrong... or how other people are handling those things... in the real world... not in those entry-level articles one can find all over the internet.
There are many selling points for GraphQL that I found online... but for me, the most important are 2 of those... and I would like to share my experiences with those... as well as ask your take on them...
No under- / overfetching
Right now we use it mainly to provide data to our own frontend application... and therefore I don't get the benefit of no under-/overfetching... since I exactly know what I need anyways... and it's not like even if I would have more fields in the database that I would forward that just in case... even when the frontend doesn't need it... also usually it is not just passing through stuff from a database but there is typically business logic involved...
If we are talking about an API shared with clients outside of your team... I can actually see the benefit of this approach.
But to be honest... you could also implement a basic attribute filter or something for your rest service like ?filter=fieldname.
The ResoveField functionality seems to also lack in those regards... I couldn't find a way to share state between the "parent" and "child" of the ResolveField-Relationship other than via the return value of the parent. (Which is not optimal if you don't want the information to be accessible). Also, because it seems that you cannot really share state between your ResolveFields you will end up calling down-stream-services multiple times... for example to compute some business logic...
I see that GraphQL is trying to build something like SQL but the issue is... that databases don't have business logic in them... but this is encoded in the SQL itself... so what is the goal here? To just plain "expose" the database to the web using GraphQL and have the logic handled by the consumer client?
Get everything in a single request
That also sounds quite good at first. The only issue is.. that if you fetch too much in one single requestā¦ which means that the backend itself needs to reach out to various other systems to compile the responseā¦ this single request might take quite some time. Sometimes having multiple requests isnāt a bad thing at all. For example when displaying a page in a web application.
When loading everything in one request the minimal load time of the page would be the time of the slowest of the aggregated systems.
If you would do several requests then you could already start showing partial information while the slower requests are still being processedā¦ this would result in a more snappy feeling experience for the user.
Again, I don't want to trash-talk GraphQL.. but I would really like to understand the idea better and how other people are using it in the real world. Those are actual issues that I'm currently facing in my project and I would be grateful to get some answers :-)
