// the find
ntex-rs/ntex
framework for composable networking services
ntex is an async Rust networking framework for building HTTP servers, WebSocket handlers, and custom TCP/UDP services. It's spiritually a fork of actix-web but architecturally distinct — the `Service` trait abstraction runs through everything, so you can compose middleware and protocol handlers the same way at any layer. Aimed at developers who need actix-web's ergonomics but want more control over the underlying I/O pipeline.
Runtime flexibility is the headline feature: you pick tokio, compio, or io-uring (neon/neon-uring) at compile time via feature flags, which is genuinely useful if you're chasing throughput on Linux with io-uring without rewriting your application code. The layered architecture (ntex-service → ntex-io → ntex-net → ntex-http → ntex-web) is coherent — each crate has a clear boundary, and the filter abstraction in ntex-io makes plugging in TLS (via openssl or rustls) or custom codecs clean. ntex-bytes ships its own Bytes implementation with benchmark suite, suggesting the author actually measured rather than just imported. Active maintenance: pushed yesterday, CI covers Linux/macOS/Windows including a Miri run for UB detection.
Community and ecosystem are thin compared to axum or actix-web — 2.5k stars and 139 forks means you're mostly on your own when something breaks in production. The documentation site (ntex.rs) is sparse; there's no equivalent of axum's thorough examples or actix-web's user guide, so expect to read source code to understand non-obvious behavior. The multiple runtime backends add real complexity: the ntex-net crate has four separate I/O implementations (tokio, compio, polling, uring) that must be kept in sync, which is a maintenance burden and a source of subtle behavioral differences. No HTTP/3 or QUIC support, and given the project size, that's probably years away.