1

When using graphql, the idea is to ask what you need and only what you need, for a whole page, using a single request. Preventing request "race conditions"(lack of a better term), separate requests asking for the same data like user name.

With things like Layout RFC and React Server Components, and even hooks, theoretically each component now should be responsible for fetching its own data.

Don't get me wrong, DX wise I prefer this way more over than the prop drilling pattern of having a query run in a /page, then passing data or data.whatever down to each component

But if each component is now doing its own request, we're coming back to the REST pattern anyway. Each component does its own request, and separate requests asking for the same data like user name.

It's just being done in a different way... But it's the same thing. The only big difference I see is the apollo cache if using apollo

assisrMatheus
  • 445
  • 1
  • 5
  • 17
  • 1
    People like simple systems. GraphQL has benefits, but there's also a tremendous cost. They're not mutually exclusive, GraphQL was never going to replace REST, and whatever fetch hook you found is also not going to replace the GraphQL client. – Evert Sep 30 '22 at 17:38
  • @Evert By new fetch pattern I don't mean a fetch hook, I still mean using apollo or whatever client. But rather, how people are fetching data lately. Favoring components that fetch their own stuff. Rather then a single REST endpoint/Graphql query for each page – assisrMatheus Sep 30 '22 at 19:51
  • I'd strongly suggest trying to consider each approach for their own merit rather than chasing the new hot thing. Something that was true a year ago likely still is, or maybe it never was. I wouldn't worry too much about what everyone else is doing. There's a _very strong_ bias to novelty when it comes to what people talk/write about. – Evert Sep 30 '22 at 20:12

1 Answers1

1

But if each component is now doing its own request, we're coming back to the REST pattern anyway.

This isn't really part of "REST", its just a possible design decision which one can take.

When using graphql, the idea is to ask what you need and only what you need, for a whole page, using a single request.

Hoisting graphql queries and requesting a larger section of data is a design decision and not inherent to graphql. Nothing in the GraphQL docs says you have to have your whole page's API requirements complete in 1 request.

This doesn't mean GraphQL is not useful. GraphQL would still be being used to fetch only precisely was the component needs. GraphQLs power comes from the ability to guarantee you are only getting what you need in your scenario, not necessarily "I got everything on the entire page all at once". Again the latter is a design decision. GraphQL enables it as an option of course, but its not necessarily the defined way to do things.

In fact, one might argue component level queries are better because you can have loading states local to the component requesting the data without blocking the whole page. If you still want page-level loading states, that's now easily achieved with suspense.

You might also argue that doing more scoped queries also increases the cache hit rate if you use a client side network layer cache because the chance of everything needed being available in cache is higher.

Preventing request "race conditions"(lack of a better term), separate requests asking for the same data like user name.

You will still have this property with component level queries if you have a proper network cache store in place. Or you architecture your app such that this data is fetched in a component higher up in the component tree and passed down via context or otherwise.

adsy
  • 8,531
  • 2
  • 20
  • 31
  • "Nothing in the GraphQL docs says you have to have your whole page's API requirements complete in 1 request."-- But isn't this part of the reason people use graphql, and one of its advantadges? If not using its advantadges, why go into the trouble of using graphql instead of rest? – assisrMatheus Sep 30 '22 at 19:52
  • 1
    I think im saying component level queries does not negate graphql advntages. Its the same concept, but at component level. You are requesting what you need in the circumstances only. So that remains a reason. Think of it like this -- the cumulative effect of all the graphql queries would be literally the same as one "mega" query. When looking at all the requests together, you have only requested still, precisely what was needed overall. You still cant do that easily with REST. In graphql fetching the data you need does not mean it has to be done in one single request. – adsy Sep 30 '22 at 19:59