Feature Request: Async RequestBodyCreator for Async Auth Payload Retrieval

[lawmicha]

Use case

Integrating asynchronous token providers and SigV4 signers with Apollo iOS is challenging due to the synchronous nature of the current requestBody method in the RequestBodyCreator protocol. This limitation forces the implementation to use a semaphore when needing to wait for the async operations to finish.

Describe the solution you'd like

An asynchronous version of requestBody

func asyncRequestBody<Operation: GraphQLOperation>(
    for operation: Operation,
    sendQueryDocument: Bool,
    autoPersistQuery: Bool
  ) async throws -> JSONEncodableDictionary

Is there an existing solution or alternative approach for handling this that I might have missed?

[calvincestari]

Hi @lawmicha, we're working on a number of changes for Swift 6 and Sendable support at the moment which is requiring us to rework the network API for first-class support of Swift Concurrency. So this probably won't happen in the 1.x branch but we may be able to work this into the networking changes.

@AnthonyMDev - here's something to take note of for the work you're doing now.

[lawmicha]

Hi @calvincestari, thanks for the quick response and for sharing the plans to support Swift Concurrency.

I’d like to create a package that depends on Apollo using the upToNextMajor version from 1.x. This will provide developers with the flexibility to stay on their current version of Apollo library until they’re ready to upgrade to the latest 1.x or 2.x release. Meanwhile, they can start using the custom RequestBodyCreator I’m writing.

However, to implement a custom RequestBodyCreator, I need the requestBody method to be asynchronous. Is there a possibility to introduce this async support in 1.x? I can drive the contribution to minimize the effort on your team. My initial proposal would look like this.

• Introduce a new RequestBodyCreatorAsync protocol with an async version of requestBody. This allows developers to opt-in and ensures backward compatibility, allowing it to be shipped as a minor version update in 1.x rather than a major breaking change. Currently, I've defined it using an escaping closure, but alternatively, we can use async throws if that fits better with the Swift Concurreny plans.
• Modify WebSocketTransport.sendHelper to pivot on the async and non-async versions when calling requestBody.

I can take this forward if I can get your team's input and decisions for achieving this in 1.x.

Thank you for your consideration!

[AnthonyMDev]

Thanks for all the detailed information you've given us on your approach here. I'm going to be getting this implemented for the 2.0 version that we are currently working on.

We feel that back porting this to 1.x is not a very clean solution and we prefer to have this just wait for the coming 2.0 version.