Obviously that's not exactly how it works, but if you give your frontend engineers the full query abilities of GQL and your backend the ability to monitor and then fix bottlenecks through the GQL load tools you simply remove a lot of the conflict zones in modern development.
You can do everything you can with GQL with Rest, but you're not going to want to do it. And speaking from experience, you're not going to want to do it with Odata either unless Microsoft magically improves the experience after 10 years of it sucking.
e.g. frontend says "backend, give me the users". Then later, for every user it says "backend, given me the users favourite images". However, with graphql the frontend can say "backend, give me the users and include each favourites images".
Even if the way to retrieve it from the database is the same for the backend, there is still reduced latency because it is only
frontend->backend->db (users)->backend->db (images)->backend->frontend
instead of
frontend->backend->db (users)->backend->frontend->backend->db (images)->backend->frontend
How?
GQL still depends on an API or a database, isn’t it? And depending on where that Api or DB is located in relation to the calling user/app latency is still going to be the same? What am I missing here?
If you are implying that GQL somehow intelligently caches data, then all the issues with cache invalidation etc still would apply, correct?
The problem with some of these debates about GQL vs Rest us that you have people either saying GQL is great or bad and same with REST. I wish there is someone that breaks it down and truly explains the pros and cons of each.