4 ms·
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 experience
by chillacy 8y ago
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 8y agoThanks for the details. It was this study: http://olafhartig.de/files/HartigPerez_WWW2018_Preprint.pdf 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