Apollo 4 Cold Start Delay: API Response Logging Immediately but Repository Receives After Delay

Client SDKs
, ,
1

I’m developing an Android native app in Kotlin using Apollo 4. When I call the home page API, the HTTP Logger Interceptor logs the response immediately. However, the response only reaches my repository after roughly 1 second. I’ve identified that this delay originates from the Apollo client.

As a workaround, I introduced a 5-second delay before invoking the API on the home page, which aligns the repository timing with the logged response. I’m looking for a solution to eliminate this cold start delay from the Apollo client without having to add an artificial delay.

Has anyone experienced this issue or found a configuration or optimization that resolves this delay? Any insights or suggestions would be greatly appreciated.

1 Like
2

Hi!

Can you elaborate on what you mean by reaching your repository after a delay?

Are you saying that the first call to client.query(YourQuery()).execute() is slower the first time than subsequent times, independently of the network latency? If so, it may be that some parts of the library that are lazily initialized take a bit of time - but we haven’t seen this reported as a particularly noticeable issue in the past.

3
  • When you call the API using:
val response = client.query(YourQuery()).execute()
val data = response.data
  • The API response is immediately logged by your LoggingInterceptor.
  • However, the response.data is only populated with the actual response after the log shows the response.

I’m not sure if this is from an Apolo client, but I was just wondering if there was any chance it was from an it.

4

This is expected, right? The logger is an interceptor that is invoked at the network level, so that’s before anything is parsed and the data object is populated and returned.

If there is a long delay between these two events that may be a concern deserving to dive deeper. If this delay is long only the first time, my only guess is that parts of the library that are initialized lazily could take some time.

A few questions:

  • are you using the normalized cache?
  • what is the size of the response your getting?
  • is this on a real device or emulator? If on a device, what kind?
5

I’m sorry for the mis-typing in my previous message. I meant to say " the response.data is only populated after a delay of 1 second after the log shows the response"

  • not using any caching
  • around 2kb
  • tasted on emulator as well as real device (samsung s23)
6

Thanks!

Can you confirm that I understand correctly that this only happens on the first call, and subsequent calls (with also the same ~2Kb payloads) are faster?

7

yes same api call with same payload size is working fine in later api calls, only the first api call has this issue

8

I have created a sample project here. I also notice the first call to be slower than the subsequent ones, although with much more acceptable values:

First call took 97ms
Second call took 24ms

From what I can tell, the difference is mostly due to the first call establishing a connexion (including TLS negotiation, etc.), whereas for the next calls the connexion is reused.

But it may be different in your own case. What I suggest you do is look at this project, and see if you can spot any obvious differences between it and your own.

1 Like