[hrktb]

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.

[chillacy]

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.

[hrktb]

Thanks for the details.

It was this study: http://olafhartig.de/files/HartigPerez_WWW2018_Preprint.pdf

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