Don't use reqwest::blocking

[CGenie]

I want to create an API service, and I see reqwest::blocking is used here. Is it possible to rewrite to use async/await instead?

[jonas-schievink]

Sure, feel free to send a PR as long as it doesn't introduce any hard dependencies on any particular executor.

[Flowneee]

Hi. I am currently interested in implementing this feature, but after quick look I think that this require major changes, because existing code is heavily rely on sync functions. What should be done:

• _async version of Request::call and Request::call_url (this require some async transport);
• AsyncTransport and implementation for http.

The major problem is Parser, which rely on std::io::Read: we cannot reuse it as-is for async streams (i.e. in AsyncTransport). I see here multiple approaches:

• AsyncTransport should read entire body as string and then pass it to Parser;
• OR make Parser async:
  • write AsyncParser, which will be almost exact clone, but all methods are async (since Parser::next should be async);
  • OR change all methods of Parser to async and:
    • (reqwest-like approach) spawn separate worker and tokio runtime there, send all async tasks there and wait for task completion in sync functions;
    • OR on each async task spawn "current thread" runtime and block on this task.

I think first option is easiest to implement, but it require more memory in runtime.

Any thoughts?

[ict-cloud]

I just came across the same limitation as @CGenie mentioned in the original post, but I do only have the restriction that the reqwest::blocking cannot be used within a tokio runtime where blocking is not allowed (i.e. use it within a yew_hook::use_async).
Thus probably the solution to just make the transport async, make this a feature and leave the remaining part as it is, may be a first approach.

Edit after first tries:
It seems like @Flowneee is right about his outline and the crucial part will be to overcome the Parser, which requires std::io::Read compatibility.