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
With a standard REST interface, you have to name all such combinations in advance. Possibly build custom code for each. With GraphQL, you specify them all at once, and are guided towards implementing code that will handle that. (There's no magic in GraphQL, of course, but the conceptualization alone can be useful. And if you're already in some particular ecosystem, they may have some localized magic you can use.)
You could just take your GraphQL backend and implement those specialized REST calls, sure, but then why not expose it?
There is a "standard" REST interface described in the paper on REST. There are a lot of rules/guidelines for a RESTful API but many API's don't follow them and tend to be a mix of REST and JSON RPC.
I mean, you could have also just done this with what you had.