I spend 3 years developing Niquests, and believe me, HTTP is far from easy. Being a client means you have to speak to everyone, and no one have to speak to you (RFC are nice, but in practice never applied as-is). Once you go deep under the implementation, you'll find a thousand edge cases(...). And yes, the myth that as developer http/1 is "best" only means that the underlying scheduler is weak.
today, via a dead simple script, you'll see http/2+ beat established giant in the http/1 client landscape. see https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... if you are curious.
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...
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.
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
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.
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.
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.
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...
For years, Python's Requests library was the gold standard, but it has been under feature freeze. As the web moved on, the Python ecosystem fractured: we got aiohttp (async only) and httpx (great, but currently struggles in high throughput scenarii for years with no visible solution merged so far).
I wanted the beautiful, ergonomic API of requests, but I wanted it to speak the modern web and solve most seen struggles around HTTP consumption. So I built Niquests as a drop-in replacement, you can literally do import niquests as requests. I didn't want to reinvent the wheel, I wanted to start on solid ground. Requests and urllib3 are both rock solid, so this was the starting point, learning from them and extend them for the modern web.
Under the hood, it's a different beast. I've added:
* HTTP/2 & HTTP/3 over QUIC out of the box
* Multiplexing and full thread/task safety (fixed the old concurrency bottlenecks over thousands of TCP connections)
* OS trust store support by default (no more certifi issues)
* Both sync and async support (in one library)
* Deep DNS control (DoH, DoQ, DoT, DNSSEC), "Happy Eyeballs" for fast connects
* Integrated WebSocket extension over HTTP/1, HTTP/2, and HTTP/3
* Works in WASM (Pyodide), and compatible with ASGI/WSGI apps
* And much more(...)
Here’s a real-world benchmark: Niquests completes a 1000-request multiplexed workload in 0.55s, compared to httpx (2.08s) and aiohttp (1.35s). See https://gist.github.com/Ousret/9e99b07e66eec48ccea5811775ec1... to verify yourself. And yes it does scale as long as your server can take it.
I've worked hard to make this the most advanced Python HTTP client. without losing the simplicity and readability we love from requests.
Would love feedback, technical questions (especially around HTTP/2+ and multiplexing!), or discussion about the state of Python HTTP clients.
I'm the maintainer of Niquests. It is a drop-in replacement for the Python requests library that focuses on bringing modern HTTP features to the familiar API we all know.
I started this because requests is effectively feature-frozen, but I really missed having support for newer standards like HTTP/2 and HTTP/3 without switching to a completely different tool. Not only due to Requests current state but, as some of you may be aware, httpx is in a tough situation too, risking to take the same path forward as Requests did(...)
Some of the main differences from the original library:
Modern Protocols: It supports HTTP/2 and HTTP/3 over QUIC by default with a true multiplexing support.
Async Support: You can use it synchronously just like requests, or asynchronously with await.
Security: It uses your system's OS truststore (no more bundled certs) and supports OCSP revocation checks and DNSSEC.
Performance: In our benchmarks, our multiplexing scheduler offer significant speed improvements over requests, httpx, and even aiohttp.
The goal is to let you upgrade your network stack just by changing your import to "import niquests as requests".
I'd love to hear your feedback or answer any questions about the implementation!
We (a team of 3 based in France) built this page because we were frustrated by how hard it is to own your identity online without any related knowledge.
We recently launched a tool (Happymail) to solve this, but this post is more about the philosophy of why we think the 'firstname.lastname' era is dying and why we should fix it.
reply