nestrs: a NestJS-style framework for Rust built on Axum and Tower

announcements
1

I've been building nestrs, a framework that brings the NestJS module/controller/provider model to Rust, running on top of Axum and Tower.

The motivation was simple: I wanted the structure and ergonomics of NestJS without leaving Rust. Instead of manually wiring Axum routers, state, and middleware across a growing codebase, nestrs gives you a familiar architecture with proc macros doing the heavy lifting.

Here is what a basic controller looks like:

#[module(controllers = [UserController], providers = [UserService])]
struct UserModule;

#[controller(prefix = "/users")]
struct UserController;

#[routes(state = UserService)]
impl UserController {
    #[get("/:id")]
    async fn find_one(
        Path(id): Path<u32>,
        State(svc): State<Arc<UserService>>,
    ) -> impl IntoResponse {
        svc.find(id).await
    }
}

What is included:

  • Module/controller/provider architecture with proc macros
  • DI container and application context
  • Guards, pipes, interceptors, exception filters
  • DTO validation pipeline (#[dto] with validator-style ergonomics)
  • Production controls: backpressure, rate limiting, request tracing, metrics, graceful shutdown
  • Optional crates for OpenAPI, GraphQL, WebSockets, microservices (Kafka, gRPC, NATS, MQTT, RabbitMQ), Prisma/SQLx integration, and CQRS
  • Scaffolding CLI (nestrs-scaffold) for generating modules and resources

Currently at v0.3.8, still pre-1.0. The core HTTP layer and DI are stable enough to build on, but the API can still shift before 1.0.

Repo: GitHub - Joshyahweh/nestrs: Nestrs is a Rust web framework that lets you build structured APIs using the same architectural patterns as NestJS — modules, controllers, providers, and dependency injection — while running on Axum and Tower. If your team already knows NestJS, nestrs gives you the same mental model with Rust’s performance and safety guarantees. ​ · GitHub
Docs: https://nestrs.mintlify.app/

I would really value feedback from this community, especially on API design, ergonomics, anything that looks wrong from an idiomatic Rust perspective, or things you would prioritise differently. Still early, so honest criticism is more useful than encouragement right now.

2

I guess this is rather a code-review category then, not a useful announcement?

141 Rust source files in a 2 weeks old repo, and a basic questions for “idiomatic Rust” (as well as some details of that repo) makes me wonder how much of this is fully unreviewed AI output. It’s not really clear at a glance what part of this is actually supposed to be “done”, and touched by a human, some transparency would be great! I’d personally not be interested in spending any time thinking about any code that the author themself might have spent zero time with themselves thus far.

Also the documentation pages are weird. I see lots of prose, yet which can be okay for an accompanying guide/tutorial material, but there are no actually normal (rustdoc) API docs to be found?

3

On the rustdoc point, the crates are published on docs.rs with rustdoc documentation. The Mintlify site is a separate guide on top of that, not a replacement.

On the AI question, fair and I'll be straight about it. Parts of this were AI assisted, particularly some of the optional crates and scaffolding. The core (HTTP layer, DI container, macros, guards/pipes/interceptors) I built and understand hands on. I'm also actively using nestrs as the backend framework for a real project I'm building, so this isn't just a generated repo I pushed and walked away from. Real usage is how I've been catching and fixing issues.

That said, you're right that not every line in every optional crate has had deep manual review from me yet. I'd rather be honest about that than oversell it. The intent of posting here was exactly to get the kind of scrutiny this community provides, not to claim it's fully production hardened.

4

Please don't ask people to review code that you have not reviewed and don't understand thoroughly yourself. That's not a human-human interaction.

5

I wasn't actually asking anyone to review the source code line by line. The ask was for feedback on the API design and ergonomics, the kind of thing you can get from looking at a code snippet and the docs. That's a different ask.

6

Ah, I guess you need way better discoverability then. You do have a website with subpage called “API Reference” and I didn’t find any reference to the rustdoc from there. On the other hand, now that I got the clue, I could of course find it; but looking at some random pages, e.g. https://docs.rs/nestrs/0.3.8/nestrs/core/struct.DiscoveryService.html I’m facing descriptions such as

Docs: see the mdBook Fundamentals chapter in the nestrs repo (docs/src/fundamentals.md ).

Which are equally hard to navigate. (If you want to make some mdbook the main source for more documentation of a type, it’s be quite useful to at least have a link or something like that :sweat_smile:)

Fair reply, I definitely appreciate the honesty. This is actually a serious problem I’m having every single time when looking at code repositories / APIs / code in general that has made use of AI heavily.

I - as the reader - have zero clue which are the parts that have received the most scrutiny; i.e. the parts that you’d consider most presentable yourself, and thus the parts that would be most useful to give feedback on. In my experience, code-bases with lots of AI assistance are often very hard to figure out because the whole process of how they were created - what prompts / what level of review was applied where / what experience the author has / etc… such things are really only something that exists in your memory as the author, but not something anyone else can actually know or learn.

It’s probably a structural issue because I have never ever seen a situation where I didn’t feel this problem looking at codebases, documents, etc… that had been created with AI-assistance.

I guess this reply of yours can actually be a good starting point to better know what to look at :slight_smile:

I suppose it might also be useful if you could tell us which pages on your documentation website have received the most work thus far and are the best place to look at to start looking into the project ^^

7

Really appreciate the patience here. You're right on the discoverability, the rustdoc pages should link directly to the mdBook chapters instead of just referencing them by file path. I'll fix that.

On where to start: the parts I'm most confident in and have spent the most time on are the core HTTP layer, the DI container, and the proc macros (nestrs-core and nestrs-macros). The examples/hello-app is the cleanest entry point to see how it all fits together.

The optional crates are not incomplete either. The microservices crate for example covers Kafka, MQTT, RabbitMQ, NATS, Redis, gRPC, and TCP transports with a wire conformance test suite. GraphQL and WebSockets have real implementations behind them. What they have had less of compared to the core is manual review time, so that is the honest caveat there, not that they are shallow.

The API design questions I am most interested in feedback on are around the macro ergonomics and the DI container interface. Those are the parts I would want scrutinised most.

8

You're right, my mistake.