5 ms·

Why wouldn’t you return more data for the REST API instead of making dependent requests?

ppseafield 7y ago
At my previous job we had a method that became known as a "superset". It would fetch a record and all data related to that, and then a lot of other data related to that. It would return tens of MB of XML every time. It was huge, but so many services came to depend on it because it always had that piece of data someone needed. All the data you needed was there, but every request caused a lot of memory usage and lots of database queries. GraphQL allows you to just ask for the fields you need without necessarily incurring the cost of returning anything else.
g_delgado14 7y ago
Because then 2 months later a dev refactors the front end to only require one of the fields, and suddenly you have the gorilla holding a banana and the whole jungle when all you asked for was a banana.
tedunangst 7y ago
Yeah, it'd sure be nice if there was some way for the client to specify what data it wants.
- ldiracdelta 7y ago
  I do that for my backends. On the HTTP request, the client sends a `?fields=encodeURIComponent(<JSON>)` query parameter to the server. If `fields` is present, then the API sends back the pruned version of the REST API. If `fields` is not present, then all the fields are sent back. Alternatively, you can prune the fields to a subset by default. The <JSON> looks like `{ foo=true, bar={baz=true}, bap=true} ` to imply the endpoint should send down field `foo`, nested object `bar` with only its field `baz` and the entire default nested object `bap`. I achieve this in Django Rest Framework by using meta-classes.
onion2k 7y ago
The people who write the API would need to know you want that data and implement the change, or write a new endpoint that returns the user details and the friends details in one request. With GraphQL the API wouldn't need to change; you'd just need to write the query on the frontend and it'd work. For most web apps the overhead of adding a new endpoint is small so the benefit of GraphQL is also small, but if you're Facebook then GraphQL makes a huge amount of sense.
- verletx64 7y ago
  GraphQL is not a substitute for communication. You should be communicating your query patterns because all fields are not equal.
strken 7y ago
Because loading all the friends for a user needs to be done in five different places with slightly different data in each one, and loading the data for each request takes 500ms combined but only 150ms separately, plus there are specific questions about each friend like "is this friend in event X?" that only make sense if you know what X is, and when you add a parameter like event=X you notice that there's already an event parameter that does something else and all these different cases are becoming messy, your backend logic had started to reflect the frontend, and you wish you had some kind of way to query your graph of users to retrieve exactly the fields and embedded relationships you need.
- netik 7y ago
  see, this is where things like apollo client shine. one part of the page makes a request and the rest of the page gets to use the data because now it’s in the local object cache. I get what this article is saying but there is a lot more to graphQL than reducing network RT. It’s about replacing statically defined REST API responses. As a prior commenter wrote, it’s making the backend more flexible when the front end devs change their mind.
baddox 7y ago
GraphQL can support arbitrary numbers of fields and arbitrary nesting of relationships. You can do this: { hero { name friends { name friends { name } } } } But some clients might only need this: { hero { name } } This is a small example, but it's pretty clear that "always including all fields and nested relationships in every REST API response" is not a viable solution. (GraphQL examples based on the schema used in the official documentation: https://graphql.org/learn/queries/ https://graphql.org/learn/queries/)
- xrd 7y ago
  This is the most important comment in this thread. For more, read this excellent article: https://brandur.org/graphql https://brandur.org/graphql

At my previous job we had a method that became known as a "superset". It would fetch a record and all data related to that, and then a lot of other data related to that. It would return tens of MB of XML every time. It was huge, but so many services came to depend on it because it always had that piece of data someone needed. All the data you needed was there, but every request caused a lot of memory usage and lots of database queries. GraphQL allows you to just ask for the fields you need without necessarily incurring the cost of returning anything else.

g_delgado14 7y ago

Because then 2 months later a dev refactors the front end to only require one of the fields, and suddenly you have the gorilla holding a banana and the whole jungle when all you asked for was a banana.

tedunangst 7y ago

Yeah, it'd sure be nice if there was some way for the client to specify what data it wants.

ldiracdelta 7y ago
I do that for my backends. On the HTTP request, the client sends a `?fields=encodeURIComponent(<JSON>)` query parameter to the server. If `fields` is present, then the API sends back the pruned version of the REST API. If `fields` is not present, then all the fields are sent back. Alternatively, you can prune the fields to a subset by default. The <JSON> looks like `{ foo=true, bar={baz=true}, bap=true} ` to imply the endpoint should send down field `foo`, nested object `bar` with only its field `baz` and the entire default nested object `bap`. I achieve this in Django Rest Framework by using meta-classes.

onion2k 7y ago

The people who write the API would need to know you want that data and implement the change, or write a new endpoint that returns the user details and the friends details in one request. With GraphQL the API wouldn't need to change; you'd just need to write the query on the frontend and it'd work. For most web apps the overhead of adding a new endpoint is small so the benefit of GraphQL is also small, but if you're Facebook then GraphQL makes a huge amount of sense.

verletx64 7y ago
GraphQL is not a substitute for communication. You should be communicating your query patterns because all fields are not equal.

strken 7y ago

Because loading all the friends for a user needs to be done in five different places with slightly different data in each one, and loading the data for each request takes 500ms combined but only 150ms separately, plus there are specific questions about each friend like "is this friend in event X?" that only make sense if you know what X is, and when you add a parameter like event=X you notice that there's already an event parameter that does something else and all these different cases are becoming messy, your backend logic had started to reflect the frontend, and you wish you had some kind of way to query your graph of users to retrieve exactly the fields and embedded relationships you need.

netik 7y ago
see, this is where things like apollo client shine. one part of the page makes a request and the rest of the page gets to use the data because now it’s in the local object cache. I get what this article is saying but there is a lot more to graphQL than reducing network RT. It’s about replacing statically defined REST API responses. As a prior commenter wrote, it’s making the backend more flexible when the front end devs change their mind.

baddox 7y ago

GraphQL can support arbitrary numbers of fields and arbitrary nesting of relationships. You can do this: { hero { name friends { name friends { name } } } } But some clients might only need this: { hero { name } } This is a small example, but it's pretty clear that "always including all fields and nested relationships in every REST API response" is not a viable solution. (GraphQL examples based on the schema used in the official documentation: https://graphql.org/learn/queries/ https://graphql.org/learn/queries/)

xrd 7y ago
This is the most important comment in this thread. For more, read this excellent article: https://brandur.org/graphql https://brandur.org/graphql