<@U79JY5TL3> I wanted some advice on how to wire u...

# confetti

[yschimke]

@mbonnin I wanted some advice on how to wire up Apollo ExecutionContext and use them internally.

[yschimke]

Context is https://github.com/joreilly/Confetti/pull/1001

[yschimke]

Basically I want to ensure we do the right things on Wear, based on the request and network types.

[yschimke]

So make images optional (Coil), or only perform an API request if it's the first request (not a refresh) or we have Bluetooth connection

[yschimke]

I don't think I can do this currently with Apollo

[yschimke]

I have all the OkHttp plumbing in place to choose the right network, and whether to fail it immediately.

[yschimke]

But I need to choose an approach for Apollo

[yschimke]

1. Just avoid making the call based on the network and cache state, and hope it will use the network. This unfortunately muddies up the app code, and probably means this code on Wear differs from mobile.

[yschimke]

2. Find out how to get some indication of the Cache status, or current Fetch policy, at the OkHttp layer? Seems too much logic needs to be built into Apollo

[yschimke]

3. Have a way to pass ExecutionContext through to OkHttp Request. Then set this when making the call.

[mbonnin]

Indeed the ExecutionContext isn't passed to the HttpEngine . We've had this issue previously and workarounded with HTTP headers that we would filter out before sending them

[yschimke]

Good idea

[mbonnin]

Let me know how that works, I'll also tinker with passing the ExecutionContext all the way through, that might come in handy

[yschimke]

The aim is to express the difference between, user clicking login or bookmark which should wake up network

[yschimke]

And optimistically refreshing cached content just in case which shouldnt

[mbonnin]

What if refreshing cached content and that reaches OkHttp? That would be an error, right?

[mbonnin]

(I guess I'm still trying to figure out what's wrong with your 1. solution above)

[yschimke]

Network situation may change in between

[mbonnin]

I think I got it
• Login => Bookmarks => NetworkOnly
• Refreshing Cache Content => CacheAndNetwork (but not wake up network)

[yschimke]

I'd like a solution that can guarantee a setting like "use LTE"

[yschimke]

Yep

[mbonnin]

Makes sense 👍

[yschimke]

Does the cache status get computer anywhere? Or I should split the CacheAndNetwork into separate calls?

[mbonnin]

You mean is the network call aware of a previous cache attempt (and whether it's a cache hit)? I don't think that's the case

[mbonnin]

I'll also tinker with passing the ExecutionContext all the way through,

This is what I came up with. Let me know what you think https://github.com/apollographql/apollo-kotlin/pull/5383

[yschimke]

Yeah, I think so. Would need to try. Is there an alpha phase where it's usable but not fixed permanently?

[mbonnin]

It's published to SNAPSHOTs after the merge

[yschimke]

API wise, I guess I'd wonder about extending Vs some extension point where the default is an identity impl.

[yschimke]

But that's your call. This looks like what I need

[mbonnin]

I contemplated DefaultHttpEngine(callFactory, configure: (apollographql.Request, okhttp3.Request.Builder) -> Unit) for a while but was a bit afraid this would be limited and felt a bit out of place

[mbonnin]

I'll merge so you can try the SNAPSHOTs. The whole v4 is still beta as well so we can still change things

[yschimke]

nit: Once the snapshot is available it should resolve itself. But copying code it appears UploadsHttpBody is ApolloInternal

[yschimke]

This deploy failed, will grab the next one. https://github.com/apollographql/apollo-kotlin/actions/runs/6936908864

[mbonnin]

I've relaunched the deploy, it worked this time. Re: UploadsHttpBody, I'd rather keep it ApolloInternal for now. GraphQL uploads have never been specified and have possible security issues so they'll probably become deprecated at some point