sqlx VS sea-orm

Because type correctness does not imply branch correctness. SQL has side effects of interpretation, and any string/query builder that is not aware of grammatical implications should be avoided in my opinion.

Check the query builder of sqlx [1]

[1] https://github.com/launchbadge/sqlx/blob/main/sqlx-core/src/...

For DB schema and migrations, I use sqlx-cli.

I tend to default to as few as possible, which is why when working with SQL and Rust, I almost always reach for SQLx. Setting up SQLx with AWS DSQL requires using the v4 Signature signing of my credentials as fetched from my AWS configuration. I do this work in my main function so that I can reuse the Postgres Pool in my handler without having to establish this connection outside of the Cold Start initializing cycle. That setup is reflected in the below code.

This looks like a less ergonomic version of Rust's SQLx (https://github.com/launchbadge/sqlx) but a more robust version of TypeScript's sqlx-ts (https://jasonshin.github.io/sqlx-ts/). Sqlc seems to copy the latter's unfortunate lack of inline SQL statements. Still, seems promising.

SQLx seems to do some form of this. though what you're suggesting may remove the build time dependency on "connecting" to a SQLite database.

"SQLx supports compile-time checked queries. It does not, however, do this by providing a Rust API or DSL (domain-specific language) for building queries. Instead, it provides macros that take regular SQL as input and ensure that it is valid for your database. The way this works is that SQLx connects to your development DB at compile time to have the database itself verify (and return some info on) your SQL queries."

https://github.com/launchbadge/sqlx

For PostgreSQL, the most relevent part of the code is here. With this in mind I changed some things around to rely on schemas instead of databases and even simplified some parts of the implementation as this was always meant to be for internal use only..

What exactly are you missing? I haven't really written "boring corporate backend stuff" in a few years but something like sqlx provides everything I've ever needed there.

Badges are the little rectangles you typically see at the top of a crate's README: https://github.com/launchbadge/sqlx/blob/main/README.md

SQLX has entered the chat [1].

[1] https://github.com/launchbadge/sqlx

SQL with SeaORM:

Haven't used it myself, but https://github.com/SeaQL/sea-orm seems to be popular in some communities and async

sea-orm

SeaORM has an Actix example in their GitHub. https://github.com/SeaQL/sea-orm/tree/master/examples/actix_example

SeaORM or the underlying SQLx query builder for SQL handling.

SeaORM is the most advanced ORM currently available, but a lot of people prefer to just skip ORMing and go direct to the underlying SQLx query builder.

If you want to do backend development, give actix-web or Axum a try. If you need templating, take a look at Maud and if you want an ORM, take a look at SeaORM.

SeaORM is the most advanced option right now (though a lot of people prefer to go direct to the underlying SQLx library) but it doesn't yet match Django ORM for offering auto-generation of draft database migrations, which is one of the things I'm unwilling to regress on. (i.e. so all I need to hand-edit is stuff like "that's a rename, not a remove+add" and so on)

Last I checked, authentication was weak. SeaORM is probably the most mature option if you're looking for an ORM like you'd find in another ecosystem (if you're willing to explore alternative designs, try using the underlying SQLx directly).