Documentation README

Runique — l'expérience développeur Django, en Rust type-safe

Rust Tests passing License Version Crates.io Runique

Déclarez un modèle une fois, et vous récupérez la table en base, la migration, un formulaire type-safe et un panel admin complet — sans câblage supplémentaire. Runique apporte la productivité de Django à Rust sans vous demander de renoncer à sa sécurité ni à ses performances. Construit sur Axum, SeaORM et Tera, il s'efface une fois le code répétitif écarté.

Statut, sans détour : développement actif. Le crate du framework (runique) fait foi ; demo-app est une vraie application testée contre lui, pas une démo jetable. Le panel admin est en bêta. Rien ci-dessous n'est enjolivé — voir l'état du projet pour la version sans filtre.

🌍 Langues : English | Français


Des macros déclaratives, pas du code répétitif

model! {
    Article,
    table: "articles",
    pk: id => Pk,
    enums: { Status: [Draft="Draft", Published="Published"], },
    {
        title:  text [required],
        slug:   text [unique],
        body:   richtext [required],
        status: choice [enum(Status), default: "Draft"],
        views:  int [default: 0],
    }
}

model! génère l'entité SeaORM (article::Model) et sa migration SQL (runique makemigrations) à partir de la même déclaration. Ajoutez #[form] et vous obtenez un formulaire type-safe correspondant, validé côté serveur et dérivable directement du schéma. Enregistrez la ressource dans admin! et le CRUD est déjà là — liste, recherche, filtres, permissions, tout y est :

admin! {
    article: article::Model => ArticleForm {
        title: "Articles",
        list_display: [["title", "Title"], ["status", "Status"], ["views", "Views"]],
        search_fields: ["title", "body"],
        list_filter:   [["status", "Status", 5]],
    }
}

Pourquoi Runique

Rust a déjà de bonnes briques web, rapides et bas niveau — ce qui lui manque, c'est un framework offrant d'entrée la productivité quotidienne de Django. Assembler soi-même un ORM, un moteur de templates, une couche de formulaires et un admin est un projet à part entière avant même d'avoir écrit une seule fonctionnalité. Runique fait ce câblage à votre place, selon un jeu de conventions cohérent, pour que le temps aille dans votre application plutôt que dans sa plomberie — sans rien perdre de la sécurité des types ni des performances de Rust.

Django (Python)Runique (Rust)
models.pymodel! → entité SeaORM + migration
forms.py#[form] formulaires type-safe
admin.pyadmin! panel admin généré
urls.pyurlpatterns! macro de routing
Templates DjangoTera (auto-échappé)
QuerySetSeaORM + DSL de requêtes search!
middlewareslots de middleware ordonnés

Pour le tableau complet : Runique vs Django.


Sécurité par défaut

Rien de tout ça n'est ajouté après coup — c'est la base dont vous partez :

Politique de sécurité


Démarrage rapide

runique new myapp
cd myapp
cargo run            # votre app est un binaire Rust normal

runique start régénère le code CRUD admin depuis vos déclarations admin!, puis lance cargo run lui-même — une étape de génération one-shot enchaînée au lancement, pas un watcher en tâche de fond (voir Admin (bêta)). Un simple cargo run saute la régénération.

Un main.rs allégé (version complète dans demo-app/src/main.rs) :

use runique::prelude::*;

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    let config = RuniqueConfig::from_env();
    let db = DatabaseConfig::from_env()?.build().connect().await?;

    RuniqueApp::builder(config)
        .routes(url::routes())
        .with_database(db)
        .statics()
        .build()
        .await
        .map_err(|e| -> Box<dyn std::error::Error> { Box::new(e) })?
        .run()
        .await?;
    Ok(())
}

Les routes passent par la macro urlpatterns! et ressortent sous forme d'un Router Axum classique :

pub fn routes() -> Router {
    urlpatterns! {
        "/"          => view!{ index },        name = "index",
        "/blog/{id}" => view!{ blog_detail },  name = "blog_detail",
    }
    .rate_limit("/login", "login", view!(login_user), 10, 60, vec![Method::POST])
}

Pour le guide complet : Installation


Contenu de ce dépôt

Version du workspace (source de vérité) : 2.2.0.


CLI

runique fournit :

⚠️ À propos du rollback de migrations runique makemigrations écrit les migrations en préservant l'ordre chronologique du système de migrations. Si vous devez un jour en revenir en arrière, passez plutôt par le CLI SeaORM : il garde la table de suivi des migrations synchronisée avec l'état réel du schéma. Mélanger les deux chemins de rollback peut désynchroniser ce suivi.


Admin (bêta)

runique start fait trois choses, dans l'ordre, sur un seul thread :

  1. il parse vos déclarations admin! dans src/admin.rs
  2. il génère le code CRUD sous src/admins/
  3. il lance cargo run --release, bloquant

Il vérifie d'abord si .with_admin(...) existe dans src/main.rs, et ne génère/lance que si c'est le cas — sinon il quitte avec un message expliquant pourquoi. Pas de surveillance continue : relancez runique start pour régénérer après une modification de src/admin.rs.

C'est encore de la bêta : les permissions fonctionnent surtout au niveau des ressources pour l'instant, le dossier généré src/admins/ est écrasé à chaque régénération, et le durcissement est en cours plutôt que terminé.

Documentation admin : Admin


Features et bases de données

Activées par défaut : orm, all-databases.

Backends sélectionnables individuellement : sqlite, postgres, mysql, mariadb.


Sessions

CleaningMemoryStore remplace le MemoryStore par défaut : il ajoute un nettoyage automatique des sessions expirées, un système de double watermark (128 Mo / 256 Mo) pour borner la mémoire, et une priorité pour les sessions authentifiées — elles sont purgées en dernier sous pression, et survivent aux redémarrages grâce à un fallback en base.

Référence complète : Sessions


Tests et couverture

cargo llvm-cov --package runique --summary-only

Détail complet par fichier : docs/couverture_test.md


Documentation


État du projet & ressources


Licence

MIT — voir LICENSE