4 ms·

> It’s the #1 reason why graphql is so popular. You only fetch what you want. It's certainly one of the main sales points for graphql. On the flip side, I've n

> It’s the #1 reason why graphql is so popular. You only fetch what you want. 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.

lukeramsden 6y ago
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.
- treve 6y ago
  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.
n_e 6y ago
> 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.
- criddell 6y ago
  > 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.
  - nojvek 6y ago
    Yes, but you don’t have that many network round trips.
    - criddell 6y ago
      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.
Xelbair 6y ago
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.
NanoWar 6y ago
You could simply use HAL with embedded resources in JSON. Not sure how the client side feels about that though
- qudat 6y ago
  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.

lukeramsden 6y ago

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.

treve 6y ago
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.

n_e 6y ago

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

criddell 6y ago
> 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.
- nojvek 6y ago
  Yes, but you don’t have that many network round trips.
  - criddell 6y ago
    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.

Xelbair 6y ago

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.

NanoWar 6y ago

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

qudat 6y ago
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.