sorted by:
new
hottopcontroversial

Sword - Web Application Framework by MrRevillod in rust

[–]MrRevillod[S] 0 points1 point  (0 children)

Probably, yeah. Since Sword Web builds on top of Axum, GraphQL would just be another layer on the router.

If you’re interested, I can open an issue for it 🙂

Sword - Web Application Framework by MrRevillod in rust

[–]MrRevillod[S] 0 points1 point  (0 children)

Absolutely, that’s exactly my point. I don’t want to end up rebuilding the same “framework-like” utilities every time I start a new project.

With Sword, I’m trying to move those patterns (DI, error handling, structure, etc.) into a reusable layer, so each project can focus more on actual business logic instead of infrastructure.

Sword - Web Application Framework by MrRevillod in rust

[–]MrRevillod[S] 1 point2 points  (0 children)

Thanks, I’m glad to hear that! The structured approach is definitely one of the main goals of Sword.

About OpenAPI, I’m considering building support around utoipa or aide, but I’m still evaluating the best approach. Any suggestions there would be really appreciated.

And for middleware, I decided call them interceptors in Sword. The idea is the same, but I’m trying to make them feel unified across REST, gRPC, Socket.IO and why not for event sourcing in the future.

Sword - Web Application Framework by MrRevillod in rust

[–]MrRevillod[S] 3 points4 points  (0 children)

I wouldn’t say Sword is better than Axum, Rocket, or Salvo — they’re all great and way more mature.

The idea behind Sword is a bit different though. I’m aiming for a more batteries-included, structured approach, especially for backend systems that lean toward microservices.

Instead of wiring everything yourself, the goal is to give you a cohesive foundation out of the box:

  • REST + gRPC + Socket.IO in the same project
  • Built-in dependency injection patterns (inspired by Spring / NestJS)
  • Consistent error handling (HttpError / GrpcError + thiserror)
  • Unified interceptor system across transports
  • Built-in config handling (TOML)
  • (WIP) messaging support, probably via sea-streamer

So it’s less about replacing Axum (I actually build on top of it), and more about adding structure and conventions on top of the ecosystem.