>My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even th

>My impression of it is that it's an "API" that's masquerading as a dumb relay, essentially giving almost datastore-level access to the frontend client (even though they don't market it that way). And this is done so that "Frontend devs" can just do "Frontend" things with access to all the data they might end up using. A bit snarky, but I do see it as a way to just "offload" the problem down the line, instead of thinking about the API-usage and what it means for potential frontend clients. That's the "old way" of doing things of course. Or to take into the account that you have no idea what people actually use your API for. Lately i had to write an simple reporting site(simple, as i work with backend and GIS mostly) - using an existing API. I need a fraction of data sent by API, but in bulk - it doesn't support that, nor i can change it. Currently i do have to make a bulk requests that includes filters on the query, then i do need to individually request each record - as bulk API does not return the bloody two extra fields i need. It turns a single query into N queries - which is slow and annoying as server cannot handle being hammered by thousands of rest API calls. Not to mention that i literally need 4 fields out of like 40. If the app implemented graphQL it would be a breeze to just fetch what i need instead of waiting minutes(!).