It's likely more of an issue if you're wanting to fetch lots of nested data in one request, but only a few specific fields of what could be an extremely large object, like say the just the names and profile picture URIs for a large set of users that have interacted with the object your fetching. This is particularly relevant to social media, such as Facebook.

For the cases we've hit, it made sense to do a more specialized endpoint (or media type) than to create a universal way to let clients pick that fields they want.

This works way nicer with caches and APIs where the URI is a first class citizen.

> On the flip side, I've never been frustrated by getting too many fields back from an API

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.

> 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.

Yes, but you don’t have that many network round trips.

Maybe, maybe not.

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.

You could simply use HAL with embedded resources in JSON. Not sure how the client side feels about that though

It's simpler if it's normalized like with JSONAPI, but all of the apps I've worked on use an E(T)L process where the transformation step normalizes the data before saving it to our cache.

I was frustrated immensely due to that.

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.