While prototype Alamofire Combine support has existed on a branch since WWDC '19, with the release of Alamofire 5 we're discussing what the real, shipped API should look like. Unlike
URLSession.DataTaskPublisher, things aren't quite as simple for Alamofire, due to the nature of our chained request APIs. For example, you can customize a
Request's behavior quite extensively just using the chained APIs:
AF.request(...) .authenticate(with: ...) .downloadProgress(...) .uploadProgress(...) .validate() .cacheResponse(using: ...) .redirect(using: ...) .cURLDescription(...) .response(...) .responseString(...) .responseDecodable(...)
While extreme, this example illustrates the amount of API that can be called on a
Request, so it's important to find a good experience with Combine to handle these calls. Of course, it could be as simple as
RequestPublisher -> Map -> ResponsePublisher, but that's not a great experience, and using
map to add the chained APIs doesn't prevent adding response handlers, which creates opportunities for misuse and bugs. We could also expose the chainable APIs we want on our
Publisher types, but as you can see that would create a rather large API surfaces that just piped to the produced
Request. If Swift could do something like this automatically it might be feasible, but I wonder if there's a better option.
In the end, it seems like we'll need a corresponding
Publisher for each
Request type we have, which each expose the chainable API of that request type as instance methods which connect to the underlying request, and then a corresponding
Publisher which knows how to add the
response methods to the
Request, and would be responsible for actually starting the request.
Any additional ideas?