[probabletrain]

What about the benefits/drawbacks of the graphql client in a web app, e.g. Apollo [1], Relay [2]? You get a client-side normalized cache of all data fetched by any query. Here's a handful of benefits:

- If data already exists in cache, a query will return that data instead of making a network request.

- Everything that has a data dependency on something in the cache will automatically update when the data is updated, e.g. after a mutation.

- Cache data can be optimistically updated before the request completes, UI that queries this data will automatically update.

- Components will automatically refetch data if they need to, e.g. if an object is partially updated.

The pain points are pretty painful though:

- Really hard to debug unexpected refetches.

- Normalizing the data for the cache comes at a cost, it can be pretty slow for big responses.

- You quickly realise you need to really understand how the client works under the hood to be productive with debugging/complex behaviour.

I see it as a case of "this is the worst API/client, except for all the others". I'm curious to hear how people using non-graphql APIs are managing data in the client in web-apps with complex data needs?

[1] https://www.apollographql.com/docs/react/why-apollo [2] https://relay.dev/

[martpie]

To me, the best feature is Relay Fragments (I think Apollo has fragments too?), as each component describes the data they need: no need to do a big top-level request then pass down the data to the responsible components, everything is in one file.

It makes UI changes much much easier to deal with.

[probabletrain]

I'm a huge fan of this. Apollo doesn't have it baked in as a pattern like Relay does afaik, but I do something similar manually in Apollo, inspired by Relay.

Deleting code automatically removes its data dependencies from the root query, it's ideal.

[phist_mcgee]

I mean technically in relay you need a parent component to make the query for the child components, and pass a reference to those children. There's still a parent/child relationship that needs to be maintained.

[travellingprog]

TanStack Query (fka React Query) is a REST client similar to Apollo Client, with many of the same pros and cons: https://tanstack.com/query/latest/docs/framework/react/overv...

[WiseWeasel]

Except it only has a query-based cache, rather than a normalized cache by type name and ID. This means a deeply nested component running a mutation to update an entity can’t update the state of a component a few levels up purely with the response to that mutation, it instead needs to invalidate the cache and cause the parent to requery, much less performant.

[romanhotsiy]

We use https://tanstack.com/query/v3 + openapi-based auto-generated SDK.

I would say the DX is pretty much comparable to using Apollo Client.

[shepherdjerred]

TanStack Query isn't a REST client. It's a generic data fetching framework.

You could use TanStack query with GraphQL, Apollo, REST, or any other data source.

[hot_gril]

I use Express for my web server and OpenAPI for the schema, which works like a charm.