Replace requests with aiohttp

[erlendvollset]

We can get performance improvements (both wrt. memory and time) by moving to asyncio and aiohttp. We can let our internal APIs be async, and then use something like this to still support the sync interface we have today. Longer term we can expose a public async API aswell.

This will require significant changes to both HTTPClient/APIClient as well as the unit tests as these are tightly coupled with the requests library by using the responses mocking library.

[thomafred]

Any update on this? Async support in general would be extremely welcome :)

[haakonvt]

@thomafred I've begun the work to move to httpx (which support both sync and async). The plan is as follows: replace requests with as few surprises as possible, then later design and decide on how we should expose the async API 😄

[thomafred]

@thomafred I've begun the work to move to httpx (which support both sync and async). The plan is as follows: replace requests with as few surprises as possible, then later design and decide on how we should expose the async API 😄

Awesome :)

[andersfylling]

What's the status on this?

Also if we just make everything async, we could auto generate a sync client that just wraps it?

[haakonvt]

What's the status on this?

@andersfylling It was not able to get this task prioritized, so I’m working on it on my own time. I’m not entirely sure when it’ll be ready, but I’m hoping after Christmas 🎄

[andersfylling]

@haakonvt let me know if you want any assistance!

[haakonvt]

Yes! 🚀 Making a temporary channel!

[andersfylling]

Just out of curiosity what is the decisions behind using httpx over aiohttp?

[haakonvt]

1. Support for both synchronous and asynchronous making the initial switch easier
2. What FastAPI uses so I assumed they made a wise choice 😅