Nestrs brings NestJS-style modules and dependency injection to Rust apps
Nestrs tried to transplant NestJS’s module-controller-provider model into Rust, and the eye-catching detail was a 141-file repo only two weeks old.

Nestrs landed on the Rust forum on April 21 with a blunt pitch: bring the NestJS module-controller-provider mental model to Rust, but run it on axum and Tower. The author, Joshua Ojoawo, said the goal was simple, give Rust developers NestJS-style structure and ergonomics without forcing them out of the language they already use.
That matters because the two worlds start from different assumptions. NestJS is built around modular architecture and dependency injection, with modules, controllers, providers, middleware, exception filters, pipes, guards, interceptors, GraphQL, WebSockets, and microservices all part of the same framework story. Axum, by contrast, is intentionally leaner. It focuses on HTTP routing and request handling, leans on ergonomics and modularity, and uses Tower’s Service system instead of inventing a separate middleware layer.
Nestrs is trying to sit between those two poles. The forum post put the project at version 0.3.8 and still pre-1.0, but described the core HTTP layer and dependency injection as stable enough to build on even if the API could still shift. The repository change log framed it as an initial public workspace with core and runtime crates, macros, CLI tooling, and parity extensions, which is a stronger signal than a thin router wrapper. The surface area is broad: dependency injection, an application context, guards, pipes, interceptors, exception filters, DTO validation, backpressure, rate limiting, tracing, metrics, graceful shutdown, and planned pieces for OpenAPI, GraphQL, WebSockets, Kafka, gRPC, NATS, MQTT, RabbitMQ, Prisma, SQLx, and CQRS scaffolding.
The practical question is whether that structure actually lowers the barrier for Rust teams. In nestrs, a feature looks like a NestJS feature: declare a module, attach a controller, inject providers, and let the framework thread state through the app. In idiomatic axum, the same job is usually handled by composing a Router, passing shared data through State, and wiring handlers and Tower middleware directly. That difference is the whole bet. Nestrs is telling NestJS users they can keep the architecture they know while gaining Rust’s compile-time safety, explicit typing, and native async performance.
The announcement also drew skepticism fast. steffahn questioned whether the project had enough human review and suggested the code might contain a lot of unreviewed AI-generated material, a reminder that Rust’s community does not treat framework polish as a substitute for code quality. Still, the project is notable for what it says about the ecosystem: one new framework was already spanning 141 Rust source files in a repo only two weeks old, and that kind of momentum suggests Rust web development is moving beyond bare routers toward heavier application structure.
Know something we missed? Have a correction or additional information?
Submit a Tip

