3 ms·
The basis of httpx is not very good at all. I think that it owes its success to be first "port" of python requests to support async, that was a strong need. B
by greatgib 7mo ago
The basis of httpx is not very good at all.
I think that it owes its success to be first "port" of python requests to support async, that was a strong need.
But otherwise it is bad: API is not that great, performance is not that great, tweaking is not that great, and the maintainer mindset is not that great also.
For the last point, few points were referenced in the article, but it can easily put your production project to suddenly break in a bad way without valid reason.
Without being perfect, I would advise everyone to switch to Aiohttp.
- mesahm 7mo agoaiohttp is an excellent library. very stable. I concurs, but! it's too heavily tied to HTTP/1, and well, I am not a fan of opening thousands of TCP conn just to keep up with HTTP/2 onward. niquests easily beat aiohttp just using 10 conn and crush httpx see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec116d https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... fwiw, HTTP/2 is twelve years old, just saying.
- sammy2255 7mo agoaiohttp is for asynchronous contexts only
- sgt 7mo agoI literally the other week had the choice between using requests and httpx. I chose httpx after deliberating a bit. I don't need async capabilities right now but I figured it'll be more consistent if that changes later.
- nyrikki 7mo agoI started using the ports and adapters pattern and protocol for any packages that have replacements or concerns. Basically treating HTTP requests as an orthogonal, or cross-cutting concern. It is sometimes hard to tell if these upstream packages are stable or abandoned. I should probably document my methodology so it can help others or at least have the chance to find out what mistakes or limitations they might have.