For fun I sometimes look here, and years ago I chose actix and Rust because it was top of the list:
Now other frameworks seem to be almost twice as fast. Looking at may_minihttp there's lots of unsafe, but xitca-web looks decent. Also actix-web remains popular, and is no longer in dire straights maintenance wise.
Any suggestions on how to pick a framework to build REST APIs that integrate with SQL databases? [e.g., with diesel; PS: also open to alternatives here because diesel is notoriously difficult to switch from one database vendor to another]
PPS: On that last point I just came across postgrpc - Rust which uses tonic - Rust so if I'm using PostgreSQL anyway might as well go whole hog
Rust web frameworks (at least the most popular / maintained ones) are not batteries-included. You have to write your own glue code with i.e. database clients and ORMs.
Nitpick: Diesel is an ORM, not a SQL database.
How come? Abstracting away the interaction with the underlying database engine is precisely the raison d’être for an ORM.
If peformance is your main concern actix is probably the best option. I prefer Axum as its built to take advantage of existing Tokio/Hyper/Tower infrastructure. Beeing part of the Tokio umbrella gives me a bit more confidence on its future.
As for ORMs, I think SeaORM is the best one out there, they also have support for GraphQL and if you want you could just use their query builder without the ORM stuff, although I ditched it for pure Sqlx I would still recommend it.
Unless you're writing an apllication that needs to suport multiple DB banckends, the ease of switching between them should probably not be a priority when deciding your tools, its a nice to have, but not a deal breaker.
Well as already pointed out in my response: If you configure diesel in a way that is incompatible with your requirements that's expected. I'm sorry, but if you cannot be bothered to just read the documentation to enable the right set of features for your requirements I fear I cannot help you anymore.
After all these restrictions exist for a good reason: Ensure that you only use features that are supported by all database systems you want to support. It's not like any library can magically emulate non-existing database features for other backends on the fly. Those that pretend to do that, usually introduce either subtitle bugs or significant performance issues.
For a good reason: It's an anti-pattern. You should always test against the same type of database system as you run in production as you otherwise will run into problems. That's at this point common knowledge.