Greetings, we are currently working on converting ...
# apollo-kotlin
f
Greetings, we are currently working on converting from our custom GraphQL client (based on OkHttp) to ApolloClient. 🧵
We have a tremendous number of OkHttp Interceptors that I'd like to continue using if possible (as opposed to converting them to ApolloInterceptors or Apollo HttpInterceptors). I understand that I can use the same OkHttpClient, but one problem I'm running into is that many of these Interceptors are checking for tags on the OkHttp Request. I know that ApolloClient has the ExecutionContext, which is similar to tags, however I don't think that will work because of this series of conversions:
Copy code
ApolloRequest -> Apollo HttpRequest -> OkHttp Request
The Apollo HttpRequest does not have a concept similar to tags and so even if I were to override the HttpRequestComposer or even the Engine, I would not be able to carry the ExecutionContext over to the OkHttpRequest. Currently the idea to beat is to have some special header that I can parse on the OkHttp side with an OkHttp Interceptor that is upstream of the others. This doesn't feel great, though I was curious if anyway had a better idea by chance?
b
If you want to pass some information from your code to an OkHttpInterceptor "through" Apollo, Http headers is also what comes to mind - can't think of any other way at the moment. Mind telling us a bit more about what information you need passing?
f
Sure, I'm auditing it right now. So far, nothing that would be too difficult to serialize into a header. Mostly just flags and options for some of our custom OkHttp Interceptors
y
It doesn't solve your problem, but if you want some custom handling for all Calls via Apollo, consider putting logic in a custom Call.Factory that decorates the OkHttpClient. You can take the headers and change back to tags before it ever gets to OkHttpClient
💡 2
Also useful if you have context available via thread locals, as it's on callers thread