oliyh / re-graph

A graphql client for clojurescript and clojure

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Question] caching and re-graph

kurt-o-sys opened this issue · comments

Does re-graph also caching like the apollo-client?
I know the apollo client has some pretty decent caching, deconstructing the queries and fetching only unknown entities. So, basically:

  1. is re-graph doing query deconstruction?
  2. is re-graph doing any kind of query/entity caching?

thx

Hi @kurt-o-sys,

The answer is no to both. If Apollo is caching on the client side how do you know you do not have stale data? How do you use such a feature?

Thanks,

Well, what apollo does is this: it leaves you in control of what exactly happens - the strategy of how/when to update to some point. First of all, the big advantage is: you can always work, whether you're online or not (which may be a big deal or not). However, these are some strategies with apollo:

  1. whenever you update an existing entity, the apollo client will send an update to the server. If there's no network, the server will not be updated :). But, it leaves you the choice to do:
  • optimistic updates (updating the local cache without updating the server, and handle it later)
  • wait for the server reply to update
  • add some kind of polling
  • subscribe to some kind of push tech (websockets) and update using websockets. Of course, when you're not online, you should handle this properly and sync first when you're online again.
  1. whenever you make a new entity, you have to explicitly add it to the local cache

(https://www.apollographql.com/docs/react/essentials/mutations.html#update)

That being said, it would be nice to have 'some' control. I like the fact that everything is stored locally as well, and that the apollo graphql browser can be used in-app (chrome debug) to run queries and check app state.
Since re-graph integrates pretty well with re-frame, I expect it may be possible to have a local copy 'denormalized' data as well, although denormalizing may be a harder (or not, not sure).

Having a kind queryable local cache of already fetched data would be nice (so to avoid unnecessary data traffic). Updating the cache in-app can be done rather automatically (optimistically or not?), adding new entities might work as well, although no id-fields are present at the time of adding them on the client, so it may not be that easy.
Updating the local cache from outside changes would be the responsibility of the user by:

  • doing some refetch in-app (polling, manual button, event based, ...) - (re)fetching automically updates the local cache
  • subscribing to some push tech (http2 sse, websockets, ...?) - same here: if one subscribes to, for example, post-entities, one should get all post entity updates and new ones and the local cache can be updated accordingly.

oh... and to answer your question about stale data: you don't know using the apollo client. (It's your responsibility to decide whether data can be stale and too what extend/on which time frame it should be synced.)

In general this sort of behaviour depends on being able to parse and understand graphql queries. re-graph doesn't do this (a query is just a string) and as it would be quite a lot of work to do so I can't forsee this happening any time soon.