Not really. With REST, the server dictates the minimum requirements of the client. In GraphQL, the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires. Also REST necessitates multiple HTTP queries to fetch multiple resources. This is not a requirement of GraphQL.
> the client dictates its own requirements, and the server is able to respond with no more and no less than what the client requires.
The burden of dictating specs is just shifted around, and it seems the workload on the server side is bigger with h GraphQL (wider range of cases to handle).
Your graphql library will handle that for you. The server defines data as it knows, the client asks for data that it wants, and the library does the transform work.
What will the library handle ?
From my understanding it’s only the query parsing and the data filtering part. Correct me if I’m wrong.
You still have to do the data mapping, fetching everything from DB in a reasonable way, and make sure it all makes sense performance wise.
All of that will be needed for any API, but it seems to me GraphQL adds the uncertainty on how much data will be exchanged (lots of small queries ? a few big queries ?), what can be optimized, how will cache behave etc.
I remember a study on te github API on how some types of queries would make it crawl excessively. It fear it becomes a nightmare to try to cover for all the cases that can go wrong.
Yes, it handles data filtering, field renaming, etc, which turns out to be a big chunk of work if you're working on APIs to support multiple frontend experiences (the BFF pattern).
I don't know what your use case is, but it sounds like you should just try it, I can only say that for us (multiple FE experiences, pushing logic to backend), it's been very good. If you have a different usecase, ymmv.
Overall it acknowledges GraphQL's advantages, while warning that the data retrieval part shouldn't be done naively.
An excerp
> We note that this issue is somehow acknowledged by the Github GraphQL interface and, as a safety measure to avoid queries that might turn out to be too resource-intensive, it introduces a few syntactic restrictions [7]. As one such restriction, Github imposes a maximum level of nesting for queries that it accepts for execution.
However, even with this restriction (and other syntactic restric- tions imposed by the Github GraphQL interface [7]), Github fails to avoid all queries that hit some resource limits when executed
