Comment by mesahm
2 months ago
the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests
I am trying to resolve what you've seen. For years of hard work.
2 months ago
the http landscape is rather scary lately in Python. instead of forking join forces... See Niquests https://github.com/jawah/niquests
I am trying to resolve what you've seen. For years of hard work.
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.
I 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.
I 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.
aiohttp 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/9e99b07e66eec48ccea5811775ec1...
fwiw, HTTP/2 is twelve years old, just saying.
aiohttp is for asynchronous contexts only
We have switched to niquests in my company and yes I can confirm that it's 10x better than httpx :)
What issues do / did you have with HTTPx?
The main pain points for us were: thread-safety issues (httpx claims to be thread-safe but we hit race conditions in production), no HTTP/3 support, and the redirect behavior requiring explicit opt-in everywhere. Also the multiplexing story in httpx is quite limited compared to what niquests offers out of the box. On top of that, httpx maintenance has been slow to acknowledge valid bug reports, the thread-safety issue took over a year to even be acknowledged...
Did you have any warts when switching? httpx has been "fine" for me but this thread has me seriously considering changing to niquests.
The switch was surprisingly smooth. I think there's an official migration guide in the doc. Honestly the API is closer to the classic requests library so nobody will be lost.
nice to hear :)
It is indeed a shame that niquests isn't used more, I think trying to use the (c'est Français) argument to in French will bring you many initial users needed for the inertia
ahah, "en effet"! je m'en souviendrai.
more seriously, all that is needed is our collective effort. I've done my part by scarifying a lot of personal time for it.
I saw there are almost no bugs or things to contribute, are there other ways to help ?
1 reply →
No Trio support yet, right? That’s the main reason to use httpx for me at least, and has been since I first typed “import httpx” some years ago.
(Also the sponsorship subscription thing in the readme gives me vague rugpull vibes. Maybe I’ve just been burned too much—I don’t mean to discourage selling support in general.)
help for getting it working is appreciated, we have it in mind. duly noted about the sponsorship, we accept constructive criticism, and alternative can be considered.
Is it knee-quests or nigh-quests?
I've started seeing these emoji-prefixed commits lately now too, peculiar
it's the gitmoji thing, I really don't like it, it was a mistake. Thinking to stop it soon. I was inspired by fastapi in the early days. I prefer conventionalcommits.org
Please don't be too much inspired by FastAPI - at least regarding maintainer bus factor and documentation (FastAPI docs are essentially tutorial only), and requiring dozens of hoops to jump through to even open an issue.
1 reply →
There is a series of extensions for Vscode that add this functionality like https://github.com/ugi-dev/better-commits
ah ok, I am familiar with and not exactly against (non-emoji) commit message prefixes
1 reply →
nee-quests, I am French native.
niquests as in "niquer" ?
J'aime bien, j'aime bien
I guess kind of obvious now noticing the rhyme
2 replies →
what a delightful pun, bravo
Can confirm, more features, a breeze to switch.
Thanks, I'll link to your project
Thank you. Appreciated, you're welcome here anytime.
[flagged]