This is very useful, thanks. I've implemented similar authentication with tower_cookies in a home project, and it took me a long time to figure out; Axum is powerful but not always the most intuitive. It was a great learning experience, but I'd love to offload more of this to a crate next time.
Rust ORMs still don't feel great. They're verbose, the tooling is flaky, and they feel fly-by-night. They're surprisingly not very type safe either. I'd rather use Rust's sqlx until the Rust ORM situation improves.
Axum and Actix are already drop in replacements for something like Flask. They're mature and good at what they do.
The dream of a Rails or Django in Rust is still really far off. I'm glad the Loco folks are trying, but it needs a lot more magic and maturity to truly bear that comparison.
Back when SeaORM first released, I was excited about another ORM that supported async (as Diesel didn't have an async shim at the time), but man does it have some weird design decisions.
The underlying query builder's API is just downright odd. The ActiveRecord pattern is fine for SeaORM, but it's just... weird. The ergonomics aren't right.
It's sent me down the path of wanting to design an ORM for myself that has the ergonomics I want. Nothing really to show yet at this point, but still something I want to build out someday.
Can you please explain what you found weird? I just started using sea-query and haven't found anything super odd quite yet, but I've only written a few migrations and queries so far
Namely, it comes from their query builder's API choices. For example, from SeaQuery's README:
```
use sea_query::*;
// For example Character table with column id, character, font_size...
pub enum Character {
Table,
Id,
FontId,
FontSize,
}
// Mapping between Enum variant and its corresponding string value
impl Iden for Character {
fn unquoted(&self, s: &mut dyn std::fmt::Write) {
write!(
s,
"{}",
match self {
Self::Table => "character",
Self::Id => "id",
Self::FontId => "font_id",
Self::FontSize => "font_size",
}
)
.unwrap();
}
}
```
The idea that the `Table` is part of the `enum` is an odd choice to me. The `Iden` trait also has an odd shape and use to me, as well.
In theory, the API for SeaORM is something I like, but in practice it feels off and stilted. Still a really cool project and I hope things improve over time, but Rust is going through a lot of growing pains around ORMs and database access.
I've used it for 3-4 months in a lot of my projects. For very basic queries it worked very well and I liked it quite a bit, but as soon as I had to do something a little less standard that's where I started to see the issues.
Documentation is not really there yet and I ended up loosing tons of time trying to look for the right function in the crate that would translate in the query I had to make. I've blogged about that too if you're interested [0] (TLDR: I got back to using raw SQL)
I don't think "glue" frameworks like Loco can get us there tbh. One problem is that frameworks like Django or RoR have to be tightly integrated! Auth needs to be aware of models and sessions, autogenerated admin pages like Django have to rely on model metadata, templates and view code might need to be aware of cache busting and static file handling, etc etc. It's a tough problem and a very high barrier to creating a new comprehensive framework.
I'm using Loco a lot since half a year, and have contributed some upstream patches. It's definitely not Rails, but where I was always afraid of refactoring Python applications, that fear is pretty much gone with Loco/Rust. That, and the incredible performance make me enjoy it a lot now. You pay extra with development time, but you get it back with long term maintainability.
My main remaining gripe is the Rust compilation speed...
I looked into it recently. Apparently it has session based auth.
I tried to figure out how to do the first thing that came to mind: on an incoming request, check that the user is authenticated, and if not redirect them to a login page with a ?next= parameter to be redirected back to after login.
Couldn't find a way to do it. In Django you use the @login_required decorator on a view and that's it.
Unfortunately it seems like you have to write a custom Axum middleware to retrieve the current user and then do the redirect manually. Not many lines of code but still…
And then again manually fetch the next query parameter after login.
This is such a common pattern, I’m astonished that it’s not provided out of the box.
