🚀 Proposal: Improve Axum tooling with schema-first validation and OpenAPI integration

[joebnb]

Hi team 👋

I’ve been using Axum to build backend services and really appreciate its modular design, performance, and Rust-idiomatic architecture. That said, I’d like to suggest an improvement in Axum's developer tooling, especially around schema validation and OpenAPI integration.

💡 Background & Motivation

In recent projects, I explored Elysia.js—a Bun-based fullstack framework—and was impressed by its schema-first approach. It offers:

• Zod-based validation for body/query/path params
• Automatic OpenAPI generation from route definitions and schema
• Seamless generation of typed TypeScript clients (via openapi-typescript)
• Tight integration between runtime validation and type-safe request handling

This paradigm significantly improves DX, and makes frontend-backend collaboration much smoother.

---

🔎 How this relates to Axum

Rust has one major advantage: a powerful type system. In Axum, we often use typed structs with serde to parse requests, which is conceptually similar to Zod-based validation in TS.

However, there’s no unified mechanism to extract those Rust types into OpenAPI schemas—unless we manually duplicate everything using crates like utoipa, schemars, or salvo_openapi.

And although these third-party crates work, the current developer experience feels awkward:

• They often require redefining routes or wrapping existing handlers in special macros or builders.
• It breaks away from Axum's elegant, composable, and minimal handler-centric design.
• The friction is high when integrating with real-world Axum apps, especially if you're already deep into the Axum ecosystem.

---

🧩 Suggestion

I believe Axum could benefit from a companion crate (or official pattern) that enables:

• Declarative schema definition (reusing serde, schemars, or serde_valid)
• Unified generation of OpenAPI from handlers and their associated types
• Type-safe client generation (via openapi-typescript or Rust → TS bridges)

Instead of forcing developers to switch paradigms to adopt OpenAPI, Axum could evolve from the inside out to support schema-first APIs natively, in a way that aligns with its existing patterns and philosophy.

This would make Axum more attractive for fullstack use cases and help bridge the backend-frontend gap.

---

🧭 Philosophy

I believe modern web frameworks should support a schema-first development paradigm, where runtime validation, type safety, and API documentation all come from a single source of truth.
This enables better DX, reduces duplication, and encourages consistent API design.

---

📚 References

• Elysia Swagger Plugin
• utoipa
• schemars
• openapi-typescript

---

Thanks again for the amazing work on Axum 🙌
Would love to hear your thoughts and happy to contribute if there's alignment!

[jplatte]

Have you tried aide? I also help maintain it. I think it should tick most of your boxes.

[joebnb]

Hi, thanks for your work on aide — it really covers a lot of what we need.

I’m curious if there’s any plan or possibility to support a more plugin-like or middleware-style incremental integration for existing Axum projects?

Currently, fully switching to ApiRouter means rewriting all routes, which can be a big cost for mature projects.

If aide could provide a way to "inject" OpenAPI generation or annotations on top of normal axum::Router routes, it would greatly improve adoption and make the developer experience smoother.

Looking forward to hearing if this is on your roadmap or if there are any workarounds!

Thanks again.

[jplatte]

I'm not clear on what you mean by requiring "rewriting all routes" - can you open a discussion on the aide repo with more details, and @mention me there?