Multiple ApolloClients per URLSessionClient instances ?

[petarbelokonski]

Question

I need to be able to issue operation requests on multiple OperationQueues (say 2). That said I need to keep a reference of multiple URLSessionClient instances. What I think will work best is to keep multiple separate instances of ApoIloClient each tied up to a specific URLSessionClient. Is there a preferred/suggested way of doing that given the InterceptorProvider protocol and that we need to initialize ApolloClient with a given InterceptorProvider before making the request ?

[calvincestari]

Hi @petarbelokonski 👋🏻 - it sounds like you simply want to know how to deal with the interceptor provider, is that correct?

If so then you can reuse the DefaultInterceptorProvider, which is what's used internally and gives you the standard provider list, in both Apollo Client instances. The following code demonstrates how to do that:

let url = URL(string: "http://localhost:4000/")!
let sharedStore = ApolloStore() // will give you an InMemoryNormalizedCache
let sessionClient = URLSessionClie nt() // can pass in the session configuration if needed
let interceptorProvider = DefaultInterceptorProvider(client: sessionClient,store: sharedStore) // standard provider list
let networkTransport = RequestChainNetworkTransport(interceptorProvider: interceptorProvider, endpointURL: url)
let apolloClient = ApolloClient(networkTransport: networkTransport, store: sharedStore)

Does that answer your question or did I misunderstand?

[petarbelokonski]

@calvincestari Thanks for your reply. I know how to work with the interceptor provider - my question is a structural one:

I need to be able to use multiple URLSessionClient instances (with different operation queues) for my requests. However I have 1 InterceptorProvider instance per 1 ApolloClient instance.

The flow goes as follows:

• Create InterceptorProvider instance
• Create RequestChainNetworkTransport instance
• Create ApolloClient instance
• Send request using the ApolloClient
• InterceptorProvider is asked for interceptors and a NetworkFetchInterceptor is provided which contains the URLSessionClient.

I need to be able to use multiple URLSessionClients (so that I can use multiple OperationQueues, and the way I currently see this fit is to have an ApolloClient instance tied up to a concrete URLSessionClient and concrete OperationQueue - do you think this approach is fine or else would you be able suggest an alternative ?

[calvincestari]

I'm still not sure I 100% understand the issue but all the networking classes we've mentioned so far are pretty much linked 1:1. So the only way you would be able to use multiple URLSessionClient instances is with an entirely separate instance of ApolloClient. Whether they use the same interceptor chain is moot since each is initialized with a URL session client.

I don't see anything particularly wrong with that other than the burden of maintaining multiple clients but what I am far less certain of is whether a store instance should be shared between them. I suspect that is not advisable and could lead to some difficult to debug caching issues.

[petarbelokonski]

@calvincestari That's exactly the idea - I need to use multiple URLSessionClient instances. My thought process brought me to the idea of having a URLSessionClient instance per AplloClient instance hence multiple ApolloClient instances. However I haven't considered what you said about the store which is a valid concern.

My goal is to be able to determine which URLSessionClient to use per concrete fetch method invocation. However, I must be able to use any URLSessionClient for any GraphQLOperation. I could potentially use the interceptors(for operation) to check which is the operation but I need it to happen before that - it must happen before I call the fetch method on the ApolloClient so that I can specify which URLSessionClient to use for the current fetch flow. I can maybe create a subclass of my autogenerated GraphQLQuery type and use typecasting to determine which URLSessionClient to use but that feels wonky 🤔