Ironic brings NestJS-style modular architecture to Rust backends on top of Axum

Why I Built Ironic: Bringing Enterprise Application Architecture to Rust Without Hiding Rust Rust already has amazing web frameworks. So why build another one? It's a fair question. When I started working with Rust professionally, I wasn't looking for a new HTTP framework. Axum was already excellent. Tokio handled asynchronous execution beautifully. Tower provided an elegant middleware ecosystem. SQLx gave me compile-time checked queries. The ecosystem wasn't missing another router. What I kept missing was application architecture. After building backend systems ranging from small REST APIs to distributed microservices, I noticed something interesting. Every new project started differently. Every mature project eventually looked almost identical. The Hidden Cost of Starting From Scratch Creating a new Rust API is easy. Creating a backend that survives three years of development is a completely different challenge. The first week usually looks like this: src/ ├── main.rs ├── routes.rs ├── handlers.rs ├── services.rs └── models.rs Simple. Clean. Everyone is happy. Three months later... src/ ├── auth/ ├── users/ ├── orders/ ├── billing/ ├── notification/ ├── middleware/ ├── config/ ├── telemetry/ ├── cache/ ├── jobs/ ├── events/ ├── permissions/ ├── validation/ ├── metrics/ ├── errors/ └── ... Now the difficult questions appear. Where should dependencies live? How should features communicate? Where does authentication belong? How do background workers access shared services? How should modules be organized? How do we avoid circular dependencies? How do multiple developers work without stepping on each other? None of these problems are about HTTP. They're architecture problems. Rust Gives You Building Blocks, Not a Building One of Rust's greatest strengths is that it stays out of your way. It doesn't force a project structure. It doesn't prescribe dependency injection. It doesn't dictate application architecture. That's fantastic for flexibility. It's less fantastic when five engineers each organize the project differently. The Rust ecosystem intentionally provides powerful primitives. But enterprise applications usually require conventions. Without conventions, every team reinvents the same solutions. Every Company Eventually Builds Its Own Framework After enough projects, I noticed a pattern. Every backend team slowly accumulates infrastructure. Week after week, project after project, they build: Configuration loading Dependency wiring Authentication Authorization Validation Error handling Health checks OpenAPI Metrics Logging Background jobs Event publishing Testing utilities Eventually they stop writing business logic. They're rebuilding their internal platform. I've seen this happen repeatedly. The framework simply lives inside the company's repositories instead of being published. I decided to make mine public. That's how Ironic started. I Didn't Want to Replace Axum One misconception about Ironic is that it's trying to compete with Axum. It isn't. Axum is already one of the best HTTP frameworks available. Instead, Ironic treats Axum as infrastructure. Think of the stack like this. Application │ Ironic │ Axum │ Hyper │ Tokio Axum solves networking. Ironic solves application organization. Those are different responsibilities. Inspired by NestJS, Designed for Rust Developers coming from Node.js often ask me whether Ironic is "NestJS for Rust." The answer is both yes and no. NestJS influenced the developer experience. It did not influence the implementation. NestJS relies heavily on: runtime reflection metadata inspection decorators dynamic dependency containers Rust doesn't have those capabilities. More importantly... Rust doesn't need them. Instead, Ironic uses procedural macros and compile-time code generation where possible, preserving Rust's ownership model instead of replacing it with runtime magic. The goal was never to make Rust behave like TypeScript. The goal was to make large Rust applications easier to organize. Why Modules Matter More Than Routers In small applications, routing feels like the center of the project. In large applications, routing becomes almost irrelevant. Features become the real units of organization. Instead of asking: Which file contains this endpoint? You begin asking: Which business capability owns this functionality? That's why Ironic encourages applications to be organized around modules. Auth Users Orders Payments Inventory Notifications Analytics Each module owns its own: Controllers Services Repositories DTOs Configuration Events Permissions This keeps business logic cohesive instead of scattering it across the project. Dependency Injection Isn't About Magic Dependency injection has developed a bad reputation in some communities. Mostly because many frameworks hide everything behind reflection. I don't think dependency injection is the problem. Hidden dependencies are. A service should explicitly declare what it needs. The framework should simply remove repetitive wiring. If you still understand ownership, lifetimes, and trait boundaries, then Rust hasn't disappeared. That's exactly the balance I wanted. Enterprise Software Isn't Just CRUD Most tutorials build the same application. GET /users POST /users DELETE /users Real systems are much more complicated. A payment might trigger: Database transaction Cache invalidation Event publication Email notification Audit logging Analytics update Background reconciliation Suddenly you're dealing with distributed concerns rather than HTTP handlers. Architecture becomes far more important than routing. Why Compile-Time Matters One design principle guided almost every decision. If Rust can verify something at compile time, it should. Compile-time guarantees make large systems easier to maintain. They reduce runtime surprises. They improve refactoring confidence. They make teams move faster without sacrificing reliability. Rather than introducing runtime containers or reflection, I wanted Ironic to embrace Rust's philosophy. Explicit where it matters. Convenient where repetition exists. Building for Teams, Not Tutorials Many frameworks optimize for the first hour. I wanted to optimize for the third year. Questions I kept asking myself included: Can ten developers work on this project independently? Will new engineers understand the project quickly? Is each feature isolated? Can modules evolve independently? Does the architecture encourage good boundaries? Those questions shaped the framework far more than benchmark numbers. Performance Was Never the Primary Goal Rust is already fast. Axum is already fast. Tokio is already fast. Saving another few microseconds rarely determines project success. Developer productivity does. Maintainability does. Consistency does. If a framework helps engineers spend less time wiring infrastructure and more time building business logic, that's often a much bigger win than shaving another 2% off request latency. Where I Think Rust Backend Development Is Going The Rust ecosystem is maturing rapidly. Five years ago, people asked whether Rust was suitable for web development. Today that's no longer the debate. The next challenge is improving developer experience for large applications without sacrificing the qualities that make Rust unique. I believe the future isn't about hiding Rust. It's about embracing Rust while removing unnecessary repetition. That's the philosophy behind Ironic. Not replacing Axum. Not replacing Tokio. Not replacing the Rust ecosystem. Just making it easier to build backend systems that stay maintainable as they grow. Final Thoughts Ironic is still evolving, and I don't claim it has all the answers. But every design decision comes from solving the same problems repeatedly in production systems. If you've ever found yourself copying the same infrastructure into every new backend project, I'd love to hear your perspective. Maybe you've solved these problems differently. Maybe you disagree with some architectural choices. That's exactly the kind of discussion that helps the Rust ecosystem grow. Learn More 📖 Documentation: https://ironic-org.github.io/ironic ⭐ GitHub: https://github.com/ironic-org/ironic 📦 Crates.io: https://crates.io/crates/ironic If you're interested in modular Rust backends, distributed systems, or enterprise application architecture, I'd love your feedback and contributions.

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)); 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 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 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 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] 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