CacheAndNetwork fetch policy does not return the network data properly

[Veeksi]

Describe the issue
So the issue is that when the user makes a query and the network is on, the user gets cached data but not the network data.
After the user makes another query, then the network data comes also.

To Reproduce

1. Query data
2. Get data
3. Make a mutation to add something (e.g. new item)
4. Query data another time
5. Get cached data (not the new item)
6. Query second time
7. Get cached data + the new item afterwards

Expected behavior

1. Query data
2. Get data
3. Make a mutation to add something (e.g. new item)
4. Query data another time
5. Get cached data + the new item afterwards

Device / execution context
I tested above case with both Android device + emulator

Additional context
I used graphql_flutter version 5.0.2-beta.1
What backend are you trying to use?
Private API. I would like to have an public API where I can make mutations to reproduce above issue.

[budde377]

@Veeksi, maybe you can reproduce this in a test-case? See packages/graphql/test/graphql_client_test.dart for examples.

[Veeksi]

@budde377 How can I run those tests myself? Is there guide somewhere how to setup it? Should that policy work with normal query or does it need watchQuery to get network result when it is available because I used normal query? Also can mutation make it to not appear 🤔?

[budde377]

@Veeksi. I think it should work out of the box with dart test (at least that's how I'm running it).

The idea is that you can mock the server by specifying the result of queries and mutations. You don't need to use watchQuery, for an example see: https://github.com/zino-hofmann/graphql-flutter/blob/beta/packages/graphql/test/fetch_policy_test.dart#L120-L162

[Veeksi]

@budde377 Yeah, I will try to learn how to use it. I looked into it but I have no clue how can I make like a mutation that adds one repository 🤔 Like I know how can I make gql form of it, not sure how the mocked server should respond to it.

Maybe one usecase would be like this:

1. Fetch all repositories (e.g. 4 in this case)
2. Verify that there is exact number of them (4)
3. Make a mutation that creates one repository more (4+1)
4. Verify that cache returns cached ones (4) and waits that network returns the just added one within same query

[budde377]

I think you can more or less duplicate the example you have from your private API, e.g.,

when( // Setup fetch all repos
  link.request(any),
).thenAnswer(
  (_) => Stream.fromIterable([
    Response(data: ...),
  ]),
);

final rQuery1 = await client.query(QueryOptions(...)); // Fetch all repos
// Add some assertions on the result

when( // Setup add repo reply
  link.request(any),
).thenAnswer(
  (_) => Stream.fromIterable([
    Response(data: ...),
  ]),
);

final rMutate = await client.mutate(QueryOptions(...)); // Add repo
// assert something about the result.

final rQuery2 = await client.query(QueryOptions(fetchPolicy: FetchPolicy.cacheOnly)); // Check cache is updated
// Assert cache is updated

So assuming you have concrete queries and responses, you can write a test like the above setting up appropriate responses.

[Veeksi]

Hmm, I will try something tomorrow. I think I can also try to create local server and reproduce the issue that way, buts lets see! Thanks in advance :)

[Veeksi]

@budde377 I made a quick demo by creating a local go server. You can use it by reading the README and running the application. It should show the issue quite clearly. Hopefully this helps!

Link to repository: https://github.com/Veeksi/graphgl_issue

[budde377]

@Veeksi, thanks for this! If I understand you correctly:

• You're listing the todos as an array in todoQuery.
• You're adding a new todo in todoMutation.
• You're expecting the todo to be added to the array in todoQuery?

[Veeksi]

@budde377 Yep, that's correct! It should get the added todo in the second query but it doesn't appear. However, third query correctly contains it

[budde377]

Alright, so there's no general way that the client can know which array to add the result to, or even know if the result is newly created. Imagine that the list contains saved todos would you still add this upon creation? Probably not.

So you'll have to manually refetch the query.

[Veeksi]

But when refetching the added todo should appear in the list, right? Of course, normally I would add the todo to list without refetching but I guess the API should correctly show the added todo when making query after mutation?

[budde377]

Sure, but it depends who you ask:

• When querying with cacheAndNetwork, it'll immediately return the cached list. This is expected because it's what's in the cache.
• in the background, the network is fetched updating the cache, so the next time you query, it'll load the right result from cache. The method can't return two values.

You can use something like watchQuery to listen for changes like this and update your UI or choose a fetchPolicy which circumvents the cache. I'm not an expert in bloc, but this would have come out of the box if you're using graphql_flutter instead.

[vincenzopalazzo]

Sorry if I jump in, I want to add some reference about using graphql_flutter with block, there is a package that is the following one https://github.com/artflutter/graphql_flutter_bloc it implements an example to handle the subscription on the client-side.

However, I would like to say my unpopular opinion that maybe the server offers the simple API to implement the use case, and I'm strongly opinionated that the aggregation cache + network data has no sense because you will get the new data late due to the network latency so IMHO the client has no possibility to show before the new one and after the oldest at list wait for the new data before showing the screen, and this means that there is a wrong fetch policy used.

In addition, using the cache is important here, but from the server-side, in particular, you can have the server that cache operation, and invalidate the cache to each operation, in accordance with your server example. However, usually, in this case, the better thing to do is implement an additional API from your server to get the last update on the Todo list, and run two queries on the client-side, like the following one:

• cache + network policy to show the last cache status and at the same time update the cache;
• call the additional graphql method (network only) to get the update, in this way when the future will resolves you can update your view of how Instagram does with the "show latest" button.

Ah! My idea is referring to your server example, that it is the basic and more common one, so maybe all my idea can be wrong with the different server implementation.

P.S: If there is no opposition, I will move this issue to the discussion side

[Veeksi]

Yeah, I thought that CacheAndNetwork policy means that the query waits the network result and combines it to cached result if it differs and if there is no network, the app can use the cache. Also about that graphql_flutter_bloc, I don't really see a point to use it because logic between graphql and bloc is not that hard to manage and don't want to rely too much on 3rd party libraries which are not so popular.

The way that I want to approach this issue next is probably network check in repository level so I can check do I choose networkOnly policy if there is network and cacheOnly if there is no network.

It could be also nice to see if there would be that kind of policy aswell which prefers the network result and returns the cached result only if there is no network 🤔

[vincenzopalazzo]

It could be also nice to see if there would be that kind of policy aswell which prefers the network result and returns the cached result only if there is no network thinking

This could be a good option to add, it is a very common use case in the client side, what do you think @budde377

[budde377]

@Veeksi

Yeah, I thought that CacheAndNetwork policy means that the query waits the network result and combines it to cached result if it differs and if there is no network, the app can use the cache.

I understand why this might make sense in your case, but the benefit of cacheAndNetwork is that you get quick UI from the cache while keeping the cache fresh with the network request. This is arguable a more common use-case and in line with apollo.

Also about that graphql_flutter_bloc, I don't really see a point to use it because logic between graphql and bloc is not that hard to manage and don't want to rely too much on 3rd party libraries which are not so popular.

I was making a comment on bloc vs graphq_flutter. IMO bloc is really not a nice pattern with GraphQL. All the benefits of the reduced number of network requests when fetching data and not over fetching are lost here.

With graphql_flutter the cache is propagated out automatically. You can achieve this with watchQuery and bloc I assume. By calling watchQuery you'll get a stream which you can listen on and update your store.

Making a switch of fetch policy based on network availability should be fairly simple on your end. If we add something like this in the client we'll start to over-complicate the fetching logic.

What I fear with this is that we'll implement some over-complicated conditions and switches in the client, which in turn will add non trivial dependencies. Instead, I'd argue that this should live on your end since you know best when you want what policy. A switch should be fairly simple here.

[Veeksi]

Yeah, I will have to look into those watchQueries more deeply to figure out how I could benefit from those. Also l see your point in that last comment about new policy and how it could complicate things.

However, in my opinion bloc is a great state management tool and I don't see an option to not use it with graphql. Also it adds one business logic layer with repository when communicating with UI which is great in my opinion.

[budde377]

However, in my opinion bloc is a great state management tool and I don't see an option to not use it with graphql. Also it adds one business logic layer with repository when communicating with UI which is great in my opinion.

Different folks different strokes.