Query Batching in Android Client

General
, ,
1

Team,
i am using the Apollo android Client and wanted to explore the Batching Functionality, i explored the API but wanted to know the logical correctness of the code for Batched Execution of Queries.

Should we execute the queries one after another within the startBatchPoller() and stopBatchPoller() method?

BatchConfig batchConfig = new BatchConfig(true,10,15);
ApolloClient apolloClient = ApolloClient.builder()
                .serverUrl(graphQLServerURL)
                .okHttpClient(new OkHttpClient.Builder().addInterceptor(new AuthorizationInterceptor()).build())
                .batchingConfiguration(batchConfig)
                .build();

        apolloClient.startBatchPoller();
        apolloclient.enqueue(query1);
        apolloclient.enqueue(query2);
        apolloclient.enqueue(query3);
        apolloClient.stopBatchPoller();

or if there are any other ways please do let me know, how to run Queries in Batch Operation?

Thanks in Advance!!
Appreciate your help.

2

Hi! :wave:

Yes that’s how you would use it, except you will need to explicitly opt-in for batching on individual queries, with .canBeBatched(true).

Also the call stopBatchPoller can be done later, when disposing of your apolloClient.

You can have a look at a unit test showcasing this here (in Kotlin but equivalent Java code should be fairly equivalent).

3

Hi @Benoit_Lubek , is Batching part of Version 3 library? I am using 2.5.11 version of Apollo Libraries.

4

Yes, batching is also available in v3. Its usage is a bit different, but similar - you can have a look at the doc for it here.

5

Hi :wave:
I am able to use the batching functionality, however i wanted to understand few things to explore further and wanted to know with respect to Batching functionality in Android Client.

  • Is Batching Supported only in Asynchronous Query Calls only? or can we use it in a Synchronous way using RX java?

  • Just by looking at the responses received in the Asynchronous Batching call? Is there a way to find out which calls went as a single Batch Request?

  • Any document or design doc/pointers to explore the functionality further like the configuration settings that can be tweaked to get optimized results in Android like we have the following doc for React

Any pointers will be highly appreciated.

Thanks in Advance!!

6

Hi!

  • You can use Java and Rx with Apollo Kotlin but the experience may not be as optimal as using Kotlin and coroutines which is the main way to interact with the library. For a better support of Java, stay tuned, as this is part or the roadmap.
    In any case, batching works independently of using Rx or not.
  • Currently, there is no API to know whether a particular call was part of a batch or not. Could you tell us a bit more of the use case?
  • I think all the available configuration is described in the doc but if you want to explore further, you could have a look at the implementation here.
7

Thanks @Benoit_Lubek for the quick response, I was trying Batching by passing callbacks to the query Operation, Since we have a way for query to opt in and out of Batching, my concern was around how to distinguish between the queries that were a part of single batch operations and which got executed outside the batch by looking at their responses.

I can understand that looking at the code can give us a hint but for an end user who got the response. Is their a way to identify it?

Also when the request was fired as a batch operation but due to configuration parameters like (batchIntervalMillis and maxBatchSize), it got split into two batch queries. Is there a way to identify it from their responses or any other metrics using which this information can be identified?

Thanks!!

8

No such API currently exists.

my concern was around how to distinguish between the queries that were a part of single batch operations and which got executed outside the batch by looking at their responses.

Could you elaborate on why you need this information, at the moment I don’t understand what the end goal is.

Thanks!