When I started with Rust and Actix Web, I had quite a few questions about the framework, such as:
How do I organize my code (handlers, models, routes, ... )?
Which architecture to follow?
How to manage the integration of Diesel?
Because unlike some frameworks such as Spring boot, Django, Rails, ... Actix does not offer a default structure, we have the freedom to structure it as we want.
So I wrote this article to propose a clear architecture because there aren't many of them in the Rust community.
What is your opinion on using hexagonal architecture? It seems that in your current setup there is no way to e.g switch up the type of database.
In one of my Axum-projects I made interfaces (traits) for the repositories. I can have different implementations for those repos (Diesel, sqlite, even text files if somehow necessary). For each 'feature' I made use-cases.
E.g struct UserUseCases contains structs RegisterUser and LoginUser. RegisterUser takes the user repo + additional required services. In my main.rs I construct a AppState with all the use-cases which I can call from all my handlers.
This way the actual implementation the handlers use is fully abstracted from a specific choice like Diesel.
Thanks a lot for the feedback, I really appreciate it.
Regarding hexagonal architecture: I have a very positive opinion of it. Conceptually, it’s a strong approach that enforces clear boundaries and keeps business logic independent from infrastructure concerns like the database or ORM. What you describe with repository traits, multiple implementations, and use-cases is very much aligned with that philosophy, and it’s something I find very clean and elegant.
In this article, the choice was intentional to keep things simpler. The goal was to provide a first solid mental model for structuring an Actix Web project, especially for people who are new to Rust backend or coming from frameworks that impose conventions by default. Introducing hexagonal architecture from the start can be overwhelming, so I focused on a pragmatic, feature-based structure as a foundation.
That said, I really like your proposal. Abstracting the database behind traits and organizing logic around use-cases is a natural and very appealing next step. This article is meant as a first iteration, not a final destination, and your feedback fits perfectly with how I plan to evolve it.
I’m planning to implement this kind of abstraction in a follow-up, show how to transition toward a more hexagonal approach, and share the results. Thanks again for the thoughtful comment — it’s exactly the kind of discussion I was hoping this article would spark.