Comment SQLx change le travail avec les bases de données en Rust

Imaginez ceci : vous avez écrit une requête SQL complexe, compilé votre projet Rust, lancé et... obtenu une erreur runtime parce que vous avez mal orthographié un nom de colonne ou oublié de passer un argument. Agaçant, non ? Surtout dans un langage qui tire fierté de sa sécurité. C'est exactement le problème que SQLx résout.

Qu'est-ce que c'est exactement

SQLx n'est pas un ORM typique comme Hibernate ou SQLAlchemy. Les développeurs l'appellent un "toolkit SQL". La fonctionnalité principale du projet est qu'il valide vos requêtes SQL directement à la compilation. Si vous avez fait une faute de frappe dans SELECT ou si vous essayez de fourrer une chaîne là où la base de données attend un nombre, le compilateur Rust ne vous laissera tout simplement pas construire le binaire.

Le projet est entièrement asynchrone et écrit en Rust pur (sauf pour le driver SQLite, qui fait appel à une bibliothèque C). Il supporte PostgreSQL, MySQL et SQLite. Il y avait autrefois le support MSSQL, mais il a été supprimé dans la version 0.7, avec la promesse de réécrire le driver from scratch.

Validation des requêtes à la compilation

C'est probablement le point fort de la bibliothèque. Au lieu de construire des requêtes via des chaînes de méthodes (DSL), comme le font Diesel ou SeaORM, vous écrivez du SQL brut à l'intérieur d'une macro.

Comment ça marche ? Pendant la construction, SQLx se connecte à votre base de données (le chemin est spécifié dans la variable d'environnement DATABASE_URL), lui demande de valider la requête et renvoie les informations de type. Si la base de données dit que la requête est correcte, la macro génère une structure anonyme avec les résultats.

Au fait, si vous ne voulez pas que votre serveur CI frappe la base de données réelle à chaque fois pendant la construction, SQLx a un "mode hors ligne". Vous préparez le cache avec les métadonnées des requêtes une fois, et ensuite le projet se construit sans connexion réseau.

Asynchronisme et performances

SQLx a été conçu dès le départ pour async/await. Il ne cherche pas à imiter une API synchrone enveloppée dans des threads. La bibliothèque peut streamer les données : si vous devez exporter un million de lignes, vous pouvez les traiter une par une à mesure qu'elles arrivent du socket, sans remplir toute la mémoire d'un coup.

Curieusement, le projet n'est pas lié à un runtime spécifique. Vous pouvez utiliser tokio, async-std ou actix — il suffit d'activer le feature flag nécessaire dans Cargo.toml.

SQLx a été conçu dès le départ pour async/await. Il ne cherche pas à imiter une API synchrone enveloppée dans des threads. La bibliothèque peut streamer les données : si vous devez exporter un million de lignes, vous pouvez les traiter une par une à mesure qu'elles arrivent du socket, sans remplir toute la mémoire d'un coup.

Curieusement, le projet n'est pas lié à un runtime spécifique. Vous pouvez utiliser tokio, async-std ou actix — il suffit d'activer le feature flag nécessaire dans Cargo.toml.

Pourquoi ce n'est pas un ORM

SQLx n'a pas de concepts familiers comme "modèles" ou "relations". Vous ne décrivez pas User has_many Posts en code Rust. Vous décrivez JOIN dans la requête SQL.

Pour ceux qui sont habitués à avoir un contrôle total sur la base de données, c'est un énorme avantage. Vous utilisez toute la puissance de votre SGBD spécifique : des types de données spécifiques (comme JSONB dans Postgres), des fonctions de fenêtre ou des triggers complexes. SQLx s'occupe simplement du travail ennuyeux de mapper les résultats vers des structures Rust via la macro derive FromRow.

Petits détails mais utiles

La bibliothèque a beaucoup de petites choses sympas qu'on doit généralement chercher dans des plugins tiers :

• Pool de connexions intégré. Pas besoin de brancher r2d2 ou similaire.
• Support des migrations. Il y a un utilitaire CLI et la macro migrate! qui intègre les migrations directement dans votre binaire.
• Support de LISTEN/NOTIFY pour PostgreSQL out of the box.
• Gestion des transactions, y compris les transactions imbriquées via des savepoints.

Cela vaut-il la peine de l'utiliser

SQLx est parfait si vous aimez SQL et voulez utiliser les capacités de votre base de données à fond, sans perdre la sécurité des types de Rust.

Cependant, vous payez la validation des requêtes à la compilation par le temps de construction. Si vous avez des centaines de macros query!, cargo check peut devenir sensiblement plus lent. Dans de tels cas, les développeurs recommandent d'ajuster le niveau d'optimisation pour les macros dans le profil de développement :

Si vous avez besoin d'un ORM classique avec génération automatique de requêtes, vous feriez mieux de regarder SeaORM, qui, soit dit en passant, est construit sur SQLx.

Dans l'ensemble, le projet semble très mature. Il a plus de 17 000 étoiles sur GitHub et une communauté active. Si vous démarrez un nouveau backend Rust et que vous n'avez pas peur d'écrire du SQL à la main — c'est probablement le meilleur choix aujourd'hui.