So there is still calling of all the adapters, etc... which might have a bigger cost than just looking up the instance reference but it's not doing full JSON serialization either

Instead of kicking off a new

watch

call in Apollo for a given

Query<Query.Data>

, I want to attach to a

SharedFlow

that I'd manage, backed by apollo's watch

So if an object changes in Apollo cache, it'd still be emitted to all observers. The challenge I encountered now is that

val query = SomeQuery
val foo = apollo.watch(SomeQuery)
apolloStore.remove(deeplyNestedIdOfObjectInSomeQueryResponse)
val bar = apollo.watch(SomeQuery)

// foo.value = some response
// bar.value = null

Generally the fresh

watch

(

bar

) will try to read from cache, realize it can't satisfy all objects, return

null

The existing

watch

(

foo

) will not be notified of the deeply nested object removal because

remove

doesn't publish cache changes for

SomeQuery

And what just happened is that when I added caching layer, my tests started failing because I'm not doing a fresh

watch

anymore, so the app behavior changed

We'll need https://github.com/apollographql/apollo-kotlin/issues/4974. I'll give it a try this afternoon. It's been a while I haven't dug into the cache APIs so I wonder how much of a rabbit hole this will be but maybe there'll be a good surprise 🤞

I looked briefly at code around https://github.com/apollographql/apollo-kotlin/issues/4974 but I wouldn't know where to start 😕 But yeah just to clarify, it wouldn't be enough to publish changes for all the removed keys, but also for all objects referencing the removed keys. Which kind of sounds like iterating over entire cache 😬

How does SQL do it?

no idea 😄

We'd need to keep track of some kind of "backreference" or so....

For the record, this is what they do on the web: https://www.apollographql.com/docs/react/data/mutations#refetching-after-update

So either: • manually updating all the impacted places • or passing a list of affected queries that need to be refetched from the network

Anyway web approach seems reasonable. And circling back to the original problem, am I right assuming that any sort of

SharedFlow

-like cache would be out of scope for Apollo itself?

Something we could do is pass an argument to watchers to listen to all cache updates

Then the older watchers would try to re-execute the query from the cache on every change. You'll get all the updates but it's probably quite inefficient

or we could add a

ApolloStore.refetchAllWatchers()

or so

Maybe it's as simple as that indeed. I'd have to double check if the root key is in the list of watched keys

A few thoughts after letting that soak a bit and discussing it with a few other folks: •

ApolloStore.publish(rootKey)

won't work. The watchers only listen to scalar (leaf) fields, not object fields. Typically in the root key case, we don't want to get notified every time a new query queries a new root field • The web has also a garbage collector. From what I understand, this works by scanning the whole cache. If we can make it fast enough, that could maybe work. Trigger a GC and notify all dependents. • Another approach is to have every mutation return the modified objects (but requires care when writing the mutation as well as backend support)

(GC definitely sounds interesting regardless of this use case btw)