| 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/ |
It makes UI changes much much easier to deal with.