I Built a Rust Framework So Backend Development Feels Like NestJS—Without Sacrificing Rust

If you’ve ever built APIs in Rust, you’ve probably noticed something.

The ecosystem has incredible libraries:

• Axum
• Actix Web
• SQLx
• Tokio
• Tower

But once your project grows, you end up wiring everything yourself.

let user_service = UserService::new(...);
let auth_service = AuthService::new(user_service.clone(), ...);
let app = Router::new()
    .merge(auth_routes(auth_service))
    .merge(user_routes(user_service));

Enter fullscreen mode Exit fullscreen mode

There is absolutely nothing wrong with explicit composition.

In fact, that’s one of Rust’s strengths.

But after building multiple production systems, I found myself writing the same infrastructure over and over again:

• Dependency wiring
• Module organization
• Configuration loading
• Validation
• Authentication
• OpenAPI
• Background jobs
• Event handling
• CLI tools

Eventually I stopped asking:

“How do I build another backend?”

Instead I asked:

“Why am I rebuilding the backend infrastructure every single project?”

That’s how Ironic was born.

Rust Doesn’t Need Another Web Framework

Rust already has excellent web frameworks.

Axum is fantastic.

Actix is battle-tested.

Warp is powerful.

Rocket is beginner friendly.

Ironic isn’t trying to replace them.

Instead, it sits on top of Axum and focuses on application architecture rather than HTTP routing.

Think of it like this:

Tokio
   ↓
Hyper
   ↓
Axum
   ↓
Ironic

Enter fullscreen mode Exit fullscreen mode

Axum solves HTTP.

Ironic solves application structure.

Inspired by NestJS, Built the Rust Way

One thing I always appreciated about NestJS was its organization.

Projects naturally evolve into modules.

Users
Orders
Payments
Notifications

Enter fullscreen mode Exit fullscreen mode

Each feature owns:

• Controllers
• Services
• Repositories
• DTOs
• Configuration

That scales surprisingly well.

I wanted the same developer experience in Rust—but without introducing runtime reflection, decorators, or dynamic containers.

Rust deserves compile-time safety.

So Ironic uses procedural macros and compile-time metadata instead of runtime magic.

Modules Become the Building Blocks

Instead of dumping everything into main.rs, applications are composed from modules.

AuthModule
UserModule
PaymentModule
NotificationModule

Enter fullscreen mode Exit fullscreen mode

Each module explicitly defines:

• imports
• providers
• controllers
• exports

Large applications become easier to reason about because dependencies are visible instead of scattered across startup code.

Dependency Injection Without Reflection

Many developers hear “dependency injection” and immediately think:

Reflection.

Runtime containers.

Hidden magic.

Rust doesn’t need that.

Ironic performs dependency resolution while preserving Rust’s ownership model.

Services remain ordinary Rust structs.

No runtime reflection.

No hidden object graphs.

Just cleaner composition.

Batteries Included

Modern APIs require much more than routing.

Typical production projects eventually need:

• OpenAPI generation
• Validation
• Authentication
• Authorization
• Configuration
• Background jobs
• Event publishing
• Health checks
• Metrics
• Logging
• Testing utilities

Most Rust projects assemble these piece by piece.

Ironic aims to provide these capabilities under one consistent programming model so developers spend more time building business logic instead of infrastructure.

Familiar for Backend Developers

Developers coming from NestJS often recognize concepts immediately.

@Module()
↓

Module

@Controller()
↓

#[controller]

@Injectable()
↓

#[injectable]

Enter fullscreen mode Exit fullscreen mode

The goal isn’t to copy another framework.

The goal is to reduce the learning curve for backend engineers moving into Rust.

Why I Built This

Over the last few years I’ve worked on:

• high-performance APIs
• distributed systems
• microservices
• cloud-native backend platforms

Every project repeated the same architectural patterns.

Eventually the framework became inevitable.

I wanted something that lets teams focus on solving domain problems—not rebuilding application infrastructure.

Who Is Ironic For?

Ironic is a good fit if you’re building:

• SaaS platforms
• Enterprise APIs
• Microservices
• Internal developer platforms
• Large backend applications
• Teams with multiple backend developers

If you’re building a tiny CRUD API, Axum alone is probably enough.

If you’re building a backend that will live for years, architecture starts to matter much more than routing.

What’s Next?

The project is still evolving, but the long-term vision is clear:

• production-ready developer tooling
• scalable modular architecture
• compile-time safety
• first-class testing
• cloud-native deployment
• an ecosystem that feels natural to Rust developers

The objective has never been to hide Rust.

It’s to make large Rust applications easier to build, easier to maintain, and more enjoyable to work on.

I’d love feedback from the Rust community.

What architectural problems do you repeatedly solve in every backend project?

Let’s discuss.

Project

📖 Documentation: https://ironic-org.github.io/ironic

📦 Crates.io: https://crates.io/crates/ironic

⭐ GitHub: https://github.com/ironic-org/ironic