apollo-client icon indicating copy to clipboard operation
apollo-client copied to clipboard

Cold start performance issue with optimistic response

Open joebernard opened this issue 4 years ago • 4 comments

Intended outcome:

When executing a mutation, the optimistic response should be immediate for every request.

Actual outcome:

When my React Native iOS app sits in the background for a while, or after a fresh install, responses from the Optimistic Response capability can become heavily delayed for the first attempt. My UI will eventually update as the network request completes. Subsequent attempts are fast. It seems like optimistic response is not immediately ready for some reason and in some situations.

How to reproduce the issue:

Difficult to pinpoint. It occurs occasionally but usually after a fresh install, and even after letting the app fully initialize.

Versions

System: OS: macOS 11.4 Binaries: Node: 14.17.0 - /usr/local/bin/node Yarn: 1.22.5 - /usr/local/bin/yarn npm: 6.14.13 - /usr/local/bin/npm Browsers: Chrome: 91.0.4472.106 Firefox: 89.0.1 Safari: 14.1.1 npmPackages: @apollo/client: 3.3.20 => 3.3.20

joebernard avatar Jun 20 '21 23:06 joebernard

@joebernard If you're able to test with a beta release, it would be interesting to see if @apollo/[email protected] has the same issue?

Is there anything unusual about these optimistic responses? Are they especially large, or something like that?

benjamn avatar Jun 23 '21 14:06 benjamn

@benjamn I'll push that out to staging and report back. The object they return is very small. I can't think of anything out of the ordinary with them. They run fast after that initial call.

joebernard avatar Jun 23 '21 15:06 joebernard

@benjamn Upgrading to 3.4.0-rc.12 does seem to solve this issue. All optimistic responses are instantaneous now.

Can this fix be ported to the latest release or do we need to wait for 3.4.0?

I did notice that this version broke our typePolicies merge functions. We are receiving raw ref objects instead of arrays for existing arguments in some cases. In 3.3.20 these were always arrays of refs. Is this expected or should I open a separate ticket? Working around it with this

if (isReference(existing)) {
  return mergeObjects(existing, incoming);
}

joebernard avatar Jun 24 '21 15:06 joebernard

@joebernard A separate ticket would be great! If the issue is reproducible and you have time, please include a reproduction, so we can figure out exactly what's up.

benjamn avatar Jun 25 '21 17:06 benjamn