It's certainly one of the main sales points for graphql. On the flip side, I've never been frustrated by getting too many fields back from an API. I suppose if I was developing exclusively in extremely bandwidth limited contexts where getting back only 2 fields rather than 50 actually made a difference, I might care. It just seems like such a non-issue to solve/talk about in almost every other context.
This works way nicer with caches and APIs where the URI is a first class citizen.
A pretty common use-case I have is needing to support these three things :
- A “big object” list screen (where retrieving the whole objects would make the query return megabytes off data)
- A “big object” details screen (where I need the full object)
- Programmatically getting many big objects
With GraphQL it involves writing one (or two) straightforward queries, while with REST it would require more thought or code.
Aren't you just pushing the work to the back end? The GraphQL resolver is a new layer of complexity while with REST is more straightforward.
If there is some sequence that is used a lot and you've determined it to be a bottleneck, you can write a custom endpoint for it.
I could fetch the objects in bulk request.. except they didn't have the field i needed when fetched in bulk. So i had to do bulk fetch, where each object was pretty big and then fetch them again individually.
If that service supported graphql i could easily just grab what i need, without hammering the poor already over-utilized server.
This kind of issues prop up constantly especially if you use on-perm hosting.