Port async-http-client to ce3 #4149
Conversation
| () | ||
| F.delay( | ||
| httpClient.executeRequest(toAsyncRequest(req, dispatcher), asyncHandler(cb, dispatcher))) | ||
| .as(None) | ||
| }) | ||
| } | ||
|
|
||
| /** Allocates a Client and its shutdown mechanism for freeing resources. | ||
| */ | ||
| def allocate[F[_]](config: AsyncHttpClientConfig = defaultConfig)(implicit |
There was a problem hiding this comment.
Do we really need allocate and stream constructors? I have similar sentiments on apply. At this point they should probably stay for compatibility, but I think having a single resource constructor is solid (I suspect most users are using the resource constructor anyways)
There was a problem hiding this comment.
I can't remember why we did. I was going to say to DRY up with .stream, but even that uses .resource. I'd be happy to deprecate the superfluous ones.
There was a problem hiding this comment.
apply takes one that's already configured, and thus can be an implementation other than DefaultAsyncHttpClient and is to my eyes more justifiable than allocate and stream. It does feel less like an apply after getting the dispatcher argument, however. And not providing it means lifting the result into a Resource that doesn't actually shut down the client. I think you've done the best you can do here.
There was a problem hiding this comment.
We could also change the apply signature to something like:
def apply[F[_]](httpClient: AsyncHttpClient)(implicit F: Async[F]): Resource[F, Client[F]]
There was a problem hiding this comment.
Resource didn't have allocate when we initally created these.
There was a problem hiding this comment.
I don't love still calling it apply when it doesn't return the companion class (or when the return type changes!), but I prefer this signature.
There was a problem hiding this comment.
I think it's worth a rename to fromClient, will do that
|
Incorrectly autoclosed when cats-effect-3 branch was merged. |
Port async-http-client to ce3
No description provided.