Need explanation on Optimistic Updates

[subzero911]

If I use optimistic updates with CacheAndNetwork policy, how will it behave? It firstly shows optimistic value, then tries to grab the data from cache (if exists), then tries to fetch the data from network? So the optimistic value is kind of "default data", in case when we don't have cache?

[knaeckeKami]

The optimistic updates are an additional layer for responses that we expect but are not there yet.

For example for a TODO list app, when the user checks an item, you could fire a mutation that sends the checked item and fetches the new status of the item.

You could build an optimistic response that has already the new checked status of the item (which the server will probably respond with if there was no error) so the user already sees the updated UI even if the request is still in-flight.

And since the cache is normalized, even the list of items should be updated correctly if the items have an id field or you set a TypePolicy to define your own set of fields for the id.

When the response from the network arrives, the optimistic update is removed and replaced by the actual network response. When it fails, it will also remove the optimistic response.

The Cache maintains a set of optimistic responses separately from the "real" cache and merges the cached data and the optimistic data when queried.

The optimistic update is usually only used for mutations where we already know what the response will probably look like (edit operations etc) with FetchPolicy.NetworkOnly.

But the optimistic response can update listeners to other queries so they will immediately update their data.

[subzero911]

Okay, I see, by default, FetchPolicy is NetworkOnly, and optimistic data is used instead of cache. But how would it behave, if I set FetchPolicy to CacheAndNetwork?

The Cache maintains a set of optimistic responses separately from the "real" cache and merges the cached data and the optimistic data when queried.

I'm afraid I don't quite understand. Can you explain in more detail? How cached data would be merged with optimistic data? Both of them are needed?

[knaeckeKami]

It would first return the optimistic response, then cached data merged with the optimistic response, then network data.

Any other requests watching the cache might be updated when an object with an ID they are watching is updated by the optimistic response.

I'm afraid I don't quite understand. Can you explain in more detail? How cached data would be merged with optimistic data? Both of them are needed?

That's more like an implementation detail of the Cache. Nothing really to worry about. The cache maintains a set of optimistic responses that it merges into the data received from the network so that all listeners are updated with the optimistic response.

Imagine a query with for a list of items and an mutation that changes one item with an optimistic response, the cache will also update the query for the list of items with the data from the optimistic response.

[subzero911]

so that all listeners are updated with the optimistic response.

So, the optimistic response overrides an existing cached data? That's very non-obvious. I thought that priorities are: optimistic < cache < network, but it appeared to be cache < optimistic < network

[knaeckeKami]

The main use case for an optimistic response is to already update the UI for mutations where we know what the response will probably look like.

Say you have a query

query AllItems {
     items {
        id
        title
     }
}

and a mutation

mutation UpdateItem {
    updateItem(id: '1', title: 'new title') {
       id
       title
   }
}

First, you fetch data from AllItems, then the user wants to update an item and the clients calls updateItem mutation with an optimistic response.

Then, the Stream of the query for AllItems will also be updated immediately with the updated item, even though data for AllItems is already cached. It can do that because the cache normalizes it's data and it knows that the item returned from the mutation with id 1 is the same item returned from the query AllItems with id 1.

If the cache took precedence, this would not work.

Also, the optimistic response usually should only be available for a short time, since it's removed when the server responds.

[subzero911]

Also, the optimistic response usually should only be available for a short time, since it's removed when the server responds.

What if network response failed? Will the optimistic data stay in cache, or will it fallback to the old value?

[knaeckeKami]

It's also removed when the request fails. There was/is a bug that the optimistic patch would stay when the listener to the query unsubscribes before the request either succeeds or fails, this has been fixed on 0.14.0 though :)

[subzero911]

Thanks, it became clear now. In general, is ferry stable enough for production using? I'm worry about 0.xx version (not even 1.0), and "Maintainers needed" notice in the main repo page.

[knaeckeKami]

That's a question everyone has to answer on their own. I've been using ferry for over 2 years now in production. And I took over maintenance.