Hi everyone,

I've been using Axum + Tower for a few production services, and every time I start a new project I end up repeating the same setup work:

• Wiring CORS, request timeouts, rate limiting (per-IP), panic recovery (clean 500 JSON), tracing, and basic state/DI
• Making sure middleware order is correct
• Building simple controller and response conventions from scratch

It works, but it's repetitive and easy to miss something.

To reduce that friction I created a small opinionated wrapper called Oxide on top of Axum. The goal is to provide sensible production defaults and convention-over-configuration (Spring Boot-like feel) while keeping overhead very low and staying fully compatible with the Axum/Tower ecosystem.

What it adds "for free":

• Automatic middleware pipeline (rate limiting, timeouts + connection guard, panic recovery, logging, CORS, etc.)
• Simple attribute-based controllers
• Standardized JSON responses and error handling

Performance:

• Full middleware stack: 40.5k requests/sec
• Raw Axum baseline: 42.2k requests/sec
• Added overhead: only 13–19 µs per request

I've attached three screenshots:

1. Side-by-side throughput benchmark
2. The "for free" middleware pipeline
3. Boilerplate comparison (raw Axum vs Oxide)

It's still early-stage, built purely on top of excellent existing crates (no runtime reflection, no magic).

I'm sharing this here because I'd genuinely like feedback from the community:

• Do others find the initial middleware + structure setup the most annoying/repetitive part of new Axum projects?
• Would this kind of thin convention layer be useful, or do you strongly prefer staying 100% manual?

Repository: GitHub - i228808/oxide · GitHub

Happy to answer questions, take criticism, or discuss design decisions. The Rust community is usually excellent at catching bad ideas early.

Looking forward to your thoughts!

6 posts - 4 participants

Read full topic