Rust Backend Lab

L'auth JWT dans Axum comme il faut : login, refresh, middleware

2026-09-14T00:00:00+00:00

La plupart des exemples JWT avec Axum s’arrêtent au retour d’un token signé. Celui-ci couvre le cycle complet : hash argon2 des mots de passe, JWT d’accès de 15 minutes, refresh tokens de 7 jours hashés en Postgres, rotation, middleware d’auth et extracteur AuthUser.

Le modèle de tokens : accès stateless, refresh stocké

Le flow de login utilise deux types de tokens. Les tokens d’accès sont des JWT signés qui expirent en 15 minutes. Ils ne sont pas stockés en Postgres, parce que les stocker casserait l’intérêt d’un token stateless et forcerait un aller-retour BDD à chaque requête.

Les refresh tokens ne sont pas des JWT. Ce sont 64 octets aléatoires, encodés en hex, hashés en SHA-256 et stockés dans une table refresh_tokens. Le client reçoit la valeur en clair dans un cookie httpOnly. Le serveur ne voit plus que le hash après le login, donc un snapshot Postgres qui fuite ne donne pas de refresh tokens utilisables à un attaquant.

Token	État	Durée de vie	Stockage	Révocation
JWT d’accès	Stateless	15 minutes	Mémoire client ou cookie sécurisé	Expire seul, non stocké
Refresh token	Hash stocké	7 jours	`refresh_tokens.token_hash`	Flag `revoked` ou suppression de ligne

Ne stocke pas les JWT d’accès en Postgres. Garde-les courts, et fais le coûteux travail de révocation sur le refresh token.

Le piège du localStorage pour les SPA

Si tu construis une SPA navigateur, le pire endroit pour un JWT c’est localStorage. N’importe quel script injecté lit localStorage.token aussitôt. Un refresh token dans localStorage, c’est pire : il vit longtemps et laisse souvent l’attaquant se réauthentifier en silence.

Le découpage classique en prod :

Token d’accès : renvoyé dans le corps JSON, gardé en mémoire JavaScript. La SPA l’envoie avec Authorization: Bearer ....
Refresh token : posé en cookie httpOnly scopé aux routes d’auth. JavaScript ne peut pas le lire.

Le cookie httpOnly protège le refresh token contre l’exfiltration XSS. En contrepartie le CSRF devient pertinent, donc mets SameSite=Strict ou Lax, restreins le path du cookie, et fais lire le cookie (pas un corps JSON) à l’endpoint de refresh.

Si tu as déjà le squelette d’API Axum + Postgres, l’organisation du guide API REST Axum Postgres sert de base. Pour les dépendances non auth, garde la liste courte. Les choix actuels sont couverts dans les meilleures crates Rust pour une API.

Dépendances et schéma Postgres

Garde la stack d’auth petite : Axum, SQLx, jsonwebtoken, argon2, axum-extra pour les cookies, sha2 et hex pour hasher les refresh tokens.

[dependencies]
axum = "0.7"
axum-extra = { version = "0.9", features = ["cookie"] }
jsonwebtoken = "9"
argon2 = "0.5"
sqlx = { version = "0.8", features = ["runtime-tokio-rustls", "postgres", "uuid", "chrono", "migrate"] }
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
uuid = { version = "1", features = ["v4", "serde"] }
chrono = { version = "0.4", features = ["serde"] }
sha2 = "0.10"
hex = "0.4"
rand = "0.8"
thiserror = "1"
anyhow = "1"

Schéma pour les utilisateurs et les refresh tokens :

CREATE EXTENSION IF NOT EXISTS pgcrypto;

CREATE TABLE users (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  email text UNIQUE NOT NULL,
  password_hash text NOT NULL,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE TABLE refresh_tokens (
  id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  token_hash text NOT NULL UNIQUE,
  expires_at timestamptz NOT NULL,
  revoked boolean NOT NULL DEFAULT false,
  created_at timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX idx_refresh_tokens_user_id ON refresh_tokens(user_id);
CREATE INDEX idx_refresh_tokens_token_hash ON refresh_tokens(token_hash);

Le hash du refresh token est en texte parce qu’on hashe le refresh token hex en SHA-256 et on stocke le digest hex.

State applicatif, claims et helpers de tokens

Le state applicatif garde le pool Postgres et le secret JWT. Mets le secret derrière un Arc<String> pour que le middleware clone le state sans coût.

#[derive(Clone)]
pub struct AppState {
    pub db: PgPool,
    pub jwt_secret: Arc<String>,
}

const ACCESS_TTL_SECONDS: u64 = 15 * 60;
const REFRESH_TTL_DAYS: i64 = 7;

#[derive(Debug, Serialize, Deserialize)]
pub struct Claims {
    sub: String,
    email: String,
    token_type: String,
    exp: u64,
    iat: u64,
}

Signature du token d’accès :

fn sign_access_token(user_id: &Uuid, email: &str, state: &AppState) -> Result<String, AuthError> {
    let now = Utc::now().timestamp() as u64;

    let claims = Claims {
        sub: user_id.to_string(),
        email: email.to_owned(),
        token_type: "access".to_owned(),
        exp: now + ACCESS_TTL_SECONDS,
        iat: now,
    };

    Ok(jsonwebtoken::encode(
        &Header::default(),
        &claims,
        &EncodingKey::from_secret(state.jwt_secret.as_bytes()),
    )?)
}

La vérification du token d’accès contrôle l’expiration et le type :

fn decode_access_token(token: &str, state: &AppState) -> Result<Claims, AuthError> {
    let data = jsonwebtoken::decode::<Claims>(
        token,
        &DecodingKey::from_secret(state.jwt_secret.as_bytes()),
        &Validation::new(Algorithm::HS256),
    )?;

    if data.claims.token_type != "access" {
        return Err(AuthError::InvalidToken);
    }

    Ok(data.claims)
}

Les refresh tokens sont aléatoires et hashés avant de toucher la base :

fn generate_refresh_token() -> String {
    let mut bytes = [0u8; 64];
    rand::rngs::OsRng.fill_bytes(&mut bytes);
    hex::encode(bytes)
}

fn hash_refresh_token(token: &str) -> String {
    let mut hasher = Sha256::new();
    hasher.update(token.as_bytes());
    hex::encode(hasher.finalize())
}

Le login accepte email et mot de passe, vérifie le mot de passe avec argon2, puis émet un JWT d’accès court et un cookie de refresh httpOnly.

#[derive(Deserialize)]
pub struct LoginRequest {
    email: String,
    password: String,
}

#[derive(Serialize)]
pub struct AuthTokens {
    access_token: String,
    token_type: &'static str,
    expires_in: u64,
}

#[derive(sqlx::FromRow)]
struct UserRow {
    id: Uuid,
    email: String,
    password_hash: String,
}

async fn login(
    State(state): State<AppState>,
    mut jar: CookieJar,
    Json(payload): Json<LoginRequest>,
) -> Result<(CookieJar, Json<AuthTokens>), AuthError> {
    let email = payload.email.trim().to_lowercase();

    let user = sqlx::query_as::<_, UserRow>(
        "SELECT id, email, password_hash FROM users WHERE email = $1",
    )
    .bind(&email)
    .fetch_optional(&state.db)
    .await?
    .ok_or(AuthError::InvalidCredentials)?;

    let parsed_hash = PasswordHash::new(&user.password_hash)
        .map_err(|_| AuthError::InvalidCredentials)?;

    Argon2::default()
        .verify_password(payload.password.as_bytes(), &parsed_hash)
        .map_err(|_| AuthError::InvalidCredentials)?;

    let access_token = sign_access_token(&user.id, &user.email, &state)?;
    let refresh_token_plain = generate_refresh_token();
    let refresh_token_hash = hash_refresh_token(&refresh_token_plain);

    sqlx::query(
        "INSERT INTO refresh_tokens (user_id, token_hash, expires_at)
         VALUES ($1, $2, $3)",
    )
    .bind(user.id)
    .bind(&refresh_token_hash)
    .bind(Utc::now() + chrono::Duration::days(REFRESH_TTL_DAYS))
    .execute(&state.db)
    .await?;

    let mut refresh_cookie = Cookie::new("refresh_token", refresh_token_plain);
    refresh_cookie.set_path("/");
    refresh_cookie.set_http_only(true);
    refresh_cookie.set_secure(!cfg!(debug_assertions));
    refresh_cookie.set_same_site(SameSite::Strict);
    refresh_cookie.set_max_age(Duration::days(REFRESH_TTL_DAYS as u64));

    jar.add(refresh_cookie);

    Ok((
        jar,
        Json(AuthTokens {
            access_token,
            token_type: "Bearer",
            expires_in: ACCESS_TTL_SECONDS,
        }),
    ))
}

Le détail important : le refresh token en clair n’est jamais loggué ni renvoyé en JSON. La base ne stocke que son hash SHA-256.

Rotation du refresh dans une transaction

Le refresh doit faire plus que décoder un token. Il hashe la valeur du cookie, verrouille la ligne correspondante, charge l’utilisateur, révoque l’ancien token et en insère un nouveau. Un refresh token volé devient à usage unique.

#[derive(sqlx::FromRow)]
struct RefreshTokenRow {
    user_id: Uuid,
    expires_at: chrono::DateTime<chrono::Utc>,
}

async fn refresh(
    State(state): State<AppState>,
    mut jar: CookieJar,
) -> Result<(CookieJar, Json<AuthTokens>), AuthError> {
    let refresh_token_plain = jar
        .get("refresh_token")
        .ok_or(AuthError::InvalidRefreshToken)?
        .value()
        .to_owned();

    let token_hash = hash_refresh_token(&refresh_token_plain);
    let mut tx = state.db.begin().await?;

    let row = sqlx::query_as::<_, RefreshTokenRow>(
        r#"
        SELECT user_id, expires_at
        FROM refresh_tokens
        WHERE token_hash = $1
          AND revoked = false
          AND expires_at > now()
        FOR UPDATE
        "#,
    )
    .bind(&token_hash)
    .fetch_optional(&mut *tx)
    .await?
    .ok_or(AuthError::InvalidRefreshToken)?;

    sqlx::query("UPDATE refresh_tokens SET revoked = true WHERE token_hash = $1")
        .bind(&token_hash)
        .execute(&mut *tx)
        .await?;

    let user = sqlx::query_as::<_, UserRow>("SELECT id, email FROM users WHERE id = $1")
        .bind(row.user_id)
        .fetch_one(&mut *tx)
        .await?;

    let access_token = sign_access_token(&user.id, &user.email, &state)?;
    let new_refresh_token_plain = generate_refresh_token();
    let new_refresh_token_hash = hash_refresh_token(&new_refresh_token_plain);

    sqlx::query(
        "INSERT INTO refresh_tokens (user_id, token_hash, expires_at)
         VALUES ($1, $2, $3)",
    )
    .bind(user.id)
    .bind(&new_refresh_token_hash)
    .bind(Utc::now() + chrono::Duration::days(REFRESH_TTL_DAYS))
    .execute(&mut *tx)
    .await?;

    tx.commit().await?;

    let mut refresh_cookie = Cookie::new("refresh_token", new_refresh_token_plain);
    refresh_cookie.set_path("/");
    refresh_cookie.set_http_only(true);
    refresh_cookie.set_secure(!cfg!(debug_assertions));
    refresh_cookie.set_same_site(SameSite::Strict);
    refresh_cookie.set_max_age(Duration::days(REFRESH_TTL_DAYS as u64));

    jar.add(refresh_cookie);

    Ok((
        jar,
        Json(AuthTokens {
            access_token,
            token_type: "Bearer",
            expires_in: ACCESS_TTL_SECONDS,
        }),
    ))
}

Le verrou FOR UPDATE est volontaire. Si deux requêtes se battent pour le même refresh token, une seule verrouille et fait la rotation. La seconde attend, voit revoked = true, et échoue.

Middleware d’auth et extracteur `AuthUser`

Dans Axum, un middleware au niveau des routes est le bon endroit pour valider le token Bearer et insérer l’utilisateur authentifié dans les extensions de la requête. Les handlers utilisent ensuite un extracteur typé.

#[derive(Clone, Debug)]
pub struct AuthUser {
    pub id: Uuid,
    pub email: String,
}

async fn auth_middleware(
    State(state): State<AppState>,
    mut req: Request,
    next: Next,
) -> Result<Response, AuthError> {
    let token = extract_bearer_token(req.headers()).ok_or(AuthError::MissingToken)?;
    let claims = decode_access_token(token, &state)?;

    let user_id = Uuid::parse_str(&claims.sub).map_err(|_| AuthError::InvalidToken)?;

    req.extensions_mut().insert(AuthUser {
        id: user_id,
        email: claims.email,
    });

    Ok(next.run(req).await)
}

impl<S> FromRequestParts<S> for AuthUser
where
    S: Send + Sync,
{
    type Rejection = AuthError;

    async fn from_request_parts(
        parts: &mut Parts,
        _state: &S,
    ) -> Result<Self, Self::Rejection> {
        parts
            .extensions
            .get::<AuthUser>()
            .cloned()
            .ok_or(AuthError::NotAuthenticated)
    }
}

Les handlers restent propres :

async fn me(AuthUser { id, email }: AuthUser) -> Json<serde_json::Value> {
    Json(json!({
        "id": id.to_string(),
        "email": email
    }))
}

L’extracteur ne redécode pas le token. Il lit seulement la valeur insérée par le middleware, donc l’authentification a lieu une fois par requête.

Logout

Le logout suit le même flow de hash et suppression. Il supprime la ligne du refresh token en Postgres et retire le cookie.

async fn logout(
    State(state): State<AppState>,
    mut jar: CookieJar,
) -> Result<(CookieJar, StatusCode), AuthError> {
    if let Some(cookie) = jar.get("refresh_token") {
        let token_hash = hash_refresh_token(cookie.value());

        sqlx::query("DELETE FROM refresh_tokens WHERE token_hash = $1")
            .bind(&token_hash)
            .execute(&state.db)
            .await?;
    }

    jar.remove(Cookie::from("refresh_token"));

    Ok((jar, StatusCode::NO_CONTENT))
}

Le JWT d’accès reste valide jusqu’à ses 15 minutes d’expiration. Pour la plupart des API, c’est un tradeoff acceptable. Si tu as besoin d’une révocation immédiate des tokens d’accès, ajoute une petite denylist ou mets le token d’accès en base, mais ne construis ça que si un vrai besoin produit l’exige.

Câblage du router

let protected_routes = Router::new()
    .route("/me", get(me))
    .route_layer(axum::middleware::from_fn_with_state(
        state.clone(),
        auth_middleware,
    ));

let app = Router::new()
    .route("/login", post(login))
    .route("/refresh", post(refresh))
    .route("/logout", post(logout))
    .merge(protected_routes)
    .with_state(state);

Si ce découpage en modules te semble à l’étroit, la même organisation scale quand tu déplaces handlers, middleware et code de tokens dans des modules séparés. Voir comment structurer un projet web Rust pour les frontières de fichiers.

Checklist prod

Avant de shipper :

Les hashs de mots de passe utilisent argon2 avec un vrai coût mémoire.
Les tokens d’accès expirent en 15 minutes max.
Les refresh tokens sont aléatoires, hashés en Postgres, avec rotation au refresh.
Les refresh tokens utilisent des cookies httpOnly, Secure et SameSite.
La SPA n’écrit jamais de tokens dans localStorage.
Le logout révoque ou supprime le refresh token.
Rate limite /login et /refresh.
Ajoute des index sur refresh_tokens.token_hash et users.email.
Utilise TLS pour PostgreSQL en production.

Une implémentation JWT avec Axum ne vaut que par sa gestion des refresh tokens. Le JWT d’accès est facile. La rotation du refresh, son stockage hashé et la frontière du cookie httpOnly font qu’un flow de login survit à un vrai usage abusif.

Tu veux le starter complet ? Récupère mon template Axum gratuit (structure de projet + Dockerfile + CI + migrations) dans la newsletter.

Héberger un microservice Rust sur Hetzner pour 6 €/mois (Docker + CI)

2026-03-08T00:00:00+00:00

Pas besoin de Kubernetes à 80 €/mois pour ta première API Rust. Je fais tourner des petits services Axum sur un CX22 Hetzner à 6 € avec Docker et Caddy : TLS, déploiements auto, ~5k rps de marge.

Transparence : les liens ci-dessous sont affiliés. Tu paies pareil, je touche une petite commission qui finance les articles gratuits. J’utilise exactement ce setup moi-même. Alternative : DigitalOcean si tu préfères leur DX.

Pourquoi Hetzner ?

CX22 : 2 vCPU / 4 Go / 40 Go pour ~6 €/mois (Falkenstein/Nuremberg)
NVMe rapides et pas chers, bon réseau vers l’UE et les US
Tu échanges la magie managée contre du contrôle. Parfait pour des petits binaires Rust.

Besoin de US uniquement ou de Postgres managé ? Prends DigitalOcean ou Fly.io. Besoin de pas cher et rapide en Europe ? Hetzner gagne.

👉 20 € de crédit Hetzner ici (remplace YOURCODE dans config.toml)

1. Dockerfile (multi-stage, minuscule)

FROM rust:1.82-slim AS build
WORKDIR /app
COPY Cargo.toml Cargo.lock ./
COPY src ./src
COPY migrations ./migrations
RUN apt-get update && apt-get install -y pkg-config libssl-dev \
 && cargo build --release

FROM debian:bookworm-slim
RUN apt-get update && apt-get install -y ca-certificates libssl3 \
 && rm -rf /var/lib/apt/lists/*
COPY --from=build /app/target/release/rust-tasks-api /usr/local/bin/api
COPY --from=build /app/migrations ./migrations
ENV RUST_LOG=info ADDR=0.0.0.0:8080
EXPOSE 8080
CMD ["/usr/local/bin/api"]

Image de ~30 à 50 Mo. Les binaires Rust quasi statiques adorent les images slim.

2. Compose et Caddy (TLS en 5 min)

# compose.yaml
services:
  api:
    image: ghcr.io/you/rust-tasks-api:latest
    env_file: .env
    restart: unless-stopped
  caddy:
    image: caddy:2-alpine
    ports: ["80:80", "443:443"]
    volumes: ["./Caddyfile:/etc/caddy/Caddyfile", "caddy_data:/data"]
    restart: unless-stopped
volumes: { caddy_data: {} }

# Caddyfile
api.yourdomain.com {
    reverse_proxy api:8080
}

Caddy gère Let’s Encrypt tout seul. Pas de danse certbot avec nginx.

3. Déploiement CI (GitHub Actions)

name: deploy
on: { push: { branches: [main] } }
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: YOUR_GITHUB_USERNAME
          password: GHCR_TOKEN_AS_SECRET
      - uses: docker/build-push-action@v6
        with: { push: true, tags: ghcr.io/YOU/rust-tasks-api:latest }
      - name: pull and restart on VPS
        uses: appleboy/ssh-action@v1
        with:
          host: HETZNER_HOST_AS_SECRET
          username: root
          key: HETZNER_SSH_KEY_AS_SECRET
          script: |
            cd /opt/api && docker compose pull && docker compose up -d
            docker image prune -f

Push sur main, en ligne en ~2 min. Assez zéro-downtime pour une v1 (tu ajouteras du blue/green plus tard).

4. Postgres : où ?

Démarre sur le même VPS avec Docker (postgres:16-alpine, volume monté). OK jusqu’à ~10k utilisateurs.
Pour grandir, prends le Postgres managé Hetzner ou un CX22 séparé pour la BDD. Règle max_connections selon ton pool (12 à 20 par instance d’API).
Backups : pg_dump quotidien vers une Storage Box Hetzner et pgbackrest hebdo. Teste les restaurations !

Détail des coûts

VPS CX22 : ~6 €/mois
Domaine : ~12 €/an
Backups (Storage Box 100 Go) : ~1 €/mois
Total : ~8 €/mois pour une vraie API TLS qui encaisse des milliers de rps

Compare : K8s managé + LB + BDD managée, 60 à 150 €/mois pour le même trafic.

Checklist de durcissement

UFW : autorise 22/80/443 uniquement, clés SSH, fail2ban
Caddy vers l’API sur réseau Docker privé, pas d’exposition directe du 8080
RUST_LOG=info, logs JSON, /health et Uptime Kuma
Surveille le disque (les logs Docker !) : rotation max-size: "10m"

Ensuite : ajoute /metrics Prometheus avec des alertes, puis lis le guide latence p99 avant de scaler.

Comment j'ai réduit la latence p99 de 60 % sur un service Rust

2026-03-01T00:00:00+00:00

Un service Rust à 220 ms de p99 qui aurait dû être rapide. Après une semaine : 85 ms de p99 (moins 60 %), même hardware, même Postgres. Voici exactement ce qui a compté, dans l’ordre.

Stack : Axum 0.7, Tokio, SQLx, Postgres 16, un seul VPS Hetzner à 12 € + Postgres managé. Charge : ~2k rps mixtes lecture/écriture. Mesuré avec oha et des histogrammes Prometheus (pas des moyennes !).

0. Mesure la p99, pas la moyenne

La moyenne cache les queues de distribution. J’ai ajouté :

// histogram, not counter
metrics::histogram!("http_request_duration_seconds", latency);

Et j’ai dashboardé p50, p95 et p99 séparément. La p50 était déjà à 12 ms. Correct. La p99 était le problème. Des correctifs différents ciblent des percentiles différents.

Correctif 1 : pool et index manquant (moins 35 % de p99)

Deux classiques empilés :

Pool à max_connections(50) face à un petit Postgres : contention et file d’attente. Descendu à 12, avec acquire_timeout(3s). Le temps de file a disparu.
Un endpoint faisait WHERE user_id = $1 ORDER BY created_at DESC sans index composite. EXPLAIN ANALYZE montrait un seq scan sous concurrence.

CREATE INDEX CONCURRENTLY idx_tasks_user_created
  ON tasks (user_id, created_at DESC);

Résultat : p99 de 220 à 145 ms. Ennuyeux et énorme. Vérifie toujours la BDD en premier. Rust est rarement le goulot.

Correctif 2 : requêtes N+1 (moins 15 % de p99)

Une route chargeait les tâches puis bouclait un SELECT par assigné. 1 + 47 requêtes par appel à p99.

-- avant : N+1 dans une boucle Rust
-- après : un seul JOIN
SELECT t.id, t.title, u.name AS assignee
FROM tasks t LEFT JOIN users u ON u.id = t.assignee_id
WHERE t.project_id = $1;

Avec query_as! de SQLx, un seul aller-retour. p99 de 145 à 122 ms. pg_stat_statements et les spans de tracing par requête ont rendu ça évident.

Correctif 3 : allocs JSON sur le chemin chaud (moins 10 % de p99)

Le profiling avec flamegraph montrait 18 % du temps dans le churn de serde_json::Value : parse, Value, resérialisation. Correctif : désérialiser direct dans des structs, utiliser bytes::Bytes pour le passthrough, activer CompressionLayer seulement pour les gros bodies.

// mal : Json<Value> puis bidouille
// bien : DTO typé, borrow quand possible
#[derive(Deserialize)]
pub struct Ingest<'a> { #[serde(borrow)] pub title: &'a str }

p99 de 122 à 108 ms. Petit mais gratuit.

Correctif 4 : coût du tracing et des logs (moins 8 % de p99)

Niveau TRACE avec des jolis logs en prod et des bodies complets loggués. Passé à :

tracing_subscriber::fmt().json()
    .with_max_level(tracing::Level::INFO)
    .with_env_filter("myapp=info,tower_http=warn,sqlx=warn")
    .init();

Spans de debug échantillonnés, info! par ligne supprimés. p99 de 108 à 95 ms. L’observabilité ne devrait pas coûter 10 %.

Correctif 5 : timeouts et dégradation gracieuse (le reste)

Sans timeouts, un seul downstream lent empoisonne tous les workers. Ajouté :

use tower_http::timeout::TimeoutLayer;
use std::time::Duration;
// par route : appels externes 2s, acquisition BDD 3s

Plus tokio::time::timeout sur les appels reqwest sortants avec fallback sur le cache. p99 de 95 à 85 ms, et la p99.9 a arrêté de monter à plusieurs secondes.

Checklist (à voler)

Dashboarde p50/p95/p99 séparément
Pool à 10-20, acquire_timeout, surveille la profondeur de file
EXPLAIN ANALYZE sur les 5 top requêtes, ajoute des index composites
Tue les N+1 (join ou WHERE id = ANY($1))
JSON typé, évite Value sur les chemins chauds
Logs JSON en INFO, fais taire le bruit sqlx et tower_http
Timeouts partout et compression sélective
--release + lto="thin" + codegen-units=1 pour les builds prod
Teste la charge avec oha -c 100 -z 60s, pas 5s

Total : 220 à 85 ms de p99. Pas de réécriture, pas de nouvelle infra, juste de la mesure et des correctifs ennuyeux.

Tu veux la checklist complète et le JSON du dashboard Grafana ? Gratuit dans la newsletter. Je fais aussi des sprints perf d’une semaine, benchmarks avant/après inclus.

Les meilleures crates Rust pour une API en 2026

2026-02-22T00:00:00+00:00

Ne perds pas une semaine à évaluer 40 crates. Voici la stack backend 2026 tranchée que j’utilise pour chaque API Axum.

Cœur

axum 0.7 : router. Extracteurs et middlewares Tower. À associer avec tokio 1.x full.
tokio : runtime. rt-multi-thread, macros, signal (graceful shutdown !), time.
serde + serde_json : DTOs. #[serde(rename_all="camelCase")] à la frontière API, snake_case à l’intérieur.

Données

sqlx 0.8 (runtime-tokio, postgres, macros, migrate) : Postgres async avec requêtes vérifiées à la compilation. query! attrape les fautes SQL au build.
redis 0.26 / deadpool-redis : cache, rate limit et sessions. Pas de cache dans un HashMap partagé entre instances.
refinery ou sqlx::migrate! : migrations versionnées, jouées au boot. Jamais de CREATE TABLE à la main en prod.

Plomberie HTTP

tower-http : TraceLayer, CorsLayer, CompressionLayer, RequestIdLayer, TimeoutLayer. Il te faut les quatre en prod.
utoipa + utoipa-swagger-ui : OpenAPI généré depuis le code. Tes équipes front vont t’adorer.
validator (derive) : #[validate(length, email, range)] sur les DTOs d’entrée. Rejette les données pourries à la frontière.

Observabilité

tracing + tracing-subscriber (env-filter, json) : logs structurés. JSON en prod, joli en dev.
opentelemetry + tracing-opentelemetry : traces vers Jaeger ou Tempo quand les logs ne suffisent plus.
metrics + metrics-exporter-prometheus : /metrics pour le RPS, les histogrammes de latence et les stats du pool.

Robustesse

thiserror + anyhow : thiserror pour les erreurs d’API, anyhow pour les binaires et le démarrage. Un seul AppError mappé vers HTTP.
backon ou tokio-retry : backoff exponentiel pour les appels aval. Pas de boucles de retry à la main.
reqwest (rustls-tls, json) : HTTP sortant. Mets des timeouts ! Par défaut c’est infini, et c’est un tueur en prod.

Mon extrait Cargo par défaut

axum = "0.7"
tokio = { version = "1", features = ["full"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
sqlx = { version = "0.8", features = ["runtime-tokio", "postgres", "macros", "migrate", "uuid", "chrono"] }
tower-http = { version = "0.5", features = ["full"] }
tracing = "0.1"
tracing-subscriber = { version = "0.3", features = ["env-filter", "json"] }
thiserror = "2"
anyhow = "1"
validator = { version = "0.18", features = ["derive"] }
utoipa = { version = "5", features = ["axum_extras"] }

Ce que j’évite (pour des API)

Les gros ORM magiques : les requêtes SQLx explicites scalent mieux pour du backend
async-std pour des serveurs en 2026 : Tokio a gagné, l’écosystème suit
Rouler ta propre auth JWT : prends jsonwebtoken + axum-login ou une auth externalisée (Clerk/Auth0) pour démarrer

Tu veux tout ça déjà câblé ? Le template gratuit de la newsletter l’a préconfiguré, avec Dockerfile et CI.

Rust vs Go pour les microservices en 2026 : les vrais tradeoffs

2026-02-15T00:00:00+00:00

Rust vs Go, c’est une guerre de religion. Voici la version pragmatique de quelqu’un qui ship les deux : Go pour la vitesse de dev CRUD, Rust pour la latence de queue, le coût et la fiabilité à l’échelle.

En deux mots

	Rust (Axum)	Go (Chi/Gin)
Latence p50 (JSON+BDD simple)	~1 à 3 ms	~2 à 5 ms
p99 sous charge	Excellente, stable	Bonne, pauses GC visibles
Mémoire par instance	10 à 30 Mo	30 à 80 Mo
Binaire	Unique, ~5 à 15 Mo	Unique, ~10 à 20 Mo
Vitesse de dev (CRUD)	Plus lente (taxe borrow checker)	Plus rapide
Confiance au refactor	Très haute	Moyenne (les tests te portent)
Recrutement	Plus dur, plutôt senior	Plus facile
Écosystème (HTTP/ORM)	Mûrit vite (Axum, SQLx)	Très mature

Ces chiffres sont des ordres de grandeur sur un VPS Hetzner à 6 €, Postgres à côté, --release, connexions poolées. Ta charge sera différente. Benchmarke.

Où Rust gagne

1. Latence de queue. Pas de pauses GC. À 5k à 20k rps avec JSON + BDD, la p99 Rust reste plate pendant que la p99 Go tremble (surtout avec de gros heaps). Si ton SLO c’est p99 < 50ms, Rust te donne de la marge.

2. Coût. 2x moins de mémoire + plus de rps par cœur = moins d’instances. Sur Hetzner ou Fly, passer de 4 à 2 instances paie vite le temps de dev en plus.

3. Fiabilité. Result, match exhaustifs, vérification SQL à la compilation avec sqlx::query!. Des classes entières de bugs null-pointer et d’erreurs non gérées disparaissent. Refactorer 30k lignes fait se sentir en sécurité.

4. Un seul langage pour les chemins chauds. Besoin de JSON SIMD, de parsing custom ou de logique embarquée plus tard ? Tu es déjà en Rust.

Où Go gagne

1. Vitesse. net/http + sqlc/pgx + golang-migrate : du CRUD shippé en quelques heures. Rust prend 1,5 à 2x plus longtemps pour le même CRUD ennuyeux, surtout avec des juniors.

2. Recrutement. 10x plus de devs backend Go dispos. Le recrutement Rust est lent et senior.

3. Écosystème ennuyeux (en bien). Chaque middleware, chaque SDK cloud, chaque réponse StackOverflow existe. Avec Rust, il faut parfois coller des bouts.

Ma règle

CRUD interne, 3 devs, à livrer le mois prochain ? Go.
API publique, SLO p99, gros rps par cœur, sensible au coût ? Rust + Axum.
Migration ? Ne réécris pas tout. Extrais d’abord le service chaud (passerelle d’auth, bidding, ingestion). Pattern strangler. Voir mon freelance si tu veux un plan de migration.

Une tactique de migration qui marche

Mets le service Rust derrière le même Postgres / NATS / Kafka
Bascule 10 % du trafic en shadow, compare p50/p99 et taux d’erreur
Bascule route par route, garde Go en fallback pendant 2 semaines
Mesure le coût : instances, mémoire, violations p99 avant et après

Les équipes que j’accompagne voient typiquement 30 à 60 % de p99 en moins et 30 à 50 % de mémoire en moins en passant les chemins chauds de Go à Axum. Sur du CRUD ennuyeux, le gain est nul. Ne t’embête pas.

Verdict

Go optimise le débit de l’équipe. Rust optimise l’efficacité machine et la fiabilité. Choisis selon ta contrainte : time-to-market ou coût et latence à l’échelle.

Tu construis le côté Rust ? Commence par le guide Axum + Postgres et la structure de projet.

Structurer un projet web Rust (une archi Axum propre qui scale)

2026-02-08T00:00:00+00:00

La plupart des tutos Axum s’arrêtent à 3 routes dans main.rs. Un vrai service a plus de 30 routes, des jobs en tâche de fond et 3 devs. Voici la structure que j’utilise en production.

Le problème du main.rs fourre-tout

Conflits de merge à chaque PR
Aucune place définie pour la logique métier face à la glue HTTP
Impossible de tester sans lancer HTTP
Erreurs gérées de 5 façons différentes

La structure

src/
  main.rs        # 60 lignes max : config, tracing, pool, router, serve
  config.rs      # env typée
  state.rs       # AppState { db, redis, http_client, config }
  error.rs       # AppError
  extractors.rs  # AuthUser, RequestId (extracteurs custom)
  routes/        # HTTP uniquement : parse l'entrée, appelle le service, mappe la sortie
    mod.rs
    tasks.rs
    users.rs
  services/      # logique métier : quasi pure, testable
    tasks.rs
  repos/         # SQL uniquement (optionnel tant que tu n'en as pas besoin)
    tasks.rs
  models/
  middleware/
  observability.rs
tests/
  api_tasks.rs   # black-box via axum-test ou reqwest
migrations/

Règle générale : routes/ connaît HTTP, services/ non. repos/ connaît SQL, services/ n’écrit pas de SQL brut si tu les sépares.

main.rs reste bête

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let cfg = config::load()?;
    observability::init(&cfg)?;
    let db = db::connect(&cfg.database_url).await?;
    let state = AppState::new(db, cfg.clone());
    let app = routes::router(state);
    let listener = tokio::net::TcpListener::bind(cfg.addr).await?;
    tracing::info!("listening on {}", cfg.addr);
    axum::serve(listener, app).await?;
    Ok(())
}

Si ton main.rs dépasse 100 lignes, tu mélanges les responsabilités.

Les services se testent

// services/tasks.rs
pub async fn create_task(db: &PgPool, title: &str) -> Result<Task, AppError> {
    if title.trim().is_empty() {
        return Err(AppError::BadRequest("title is empty".into()));
    }
    repos::tasks::insert(db, title).await.map_err(Into::into)
}

// routes/tasks.rs: glue fine
pub async fn create_task(
    State(s): State<AppState>,
    Json(input): Json<CreateTask>,
) -> Result<impl IntoResponse, AppError> {
    let task = services::tasks::create_task(&s.db, &input.title).await?;
    Ok((StatusCode::CREATED, Json(task)))
}

Maintenant tu peux tester services::tasks::create_task avec juste une BDD, sans HTTP.

Erreurs : un seul enum

Un seul AppError pour toute l’API (voir le guide Axum + Postgres). Mapping : NotFound → 404, BadRequest → 400, Unauthorized → 401, Db → 500 (loggue tout, renvoie du générique).

Ne crée pas TaskError, UserError, AuthError sans vraie raison. Tu écrirais juste 3x des impls IntoResponse.

Config : typée, échec au démarrage

#[derive(Clone)]
pub struct Config {
    pub addr: SocketAddr,
    pub database_url: String,
}

pub fn load() -> anyhow::Result<Config> {
    dotenvy::dotenv().ok();
    Ok(Config {
        addr: std::env::var("ADDR").unwrap_or("0.0.0.0:8080".into()).parse()?,
        database_url: std::env::var("DATABASE_URL").context("DATABASE_URL missing")?,
    })
}

Échoue au boot, pas sur la première requête à 3h du matin.

Stratégie de tests

cargo test services::: tests unitaires rapides, avec sqlx::test et un vrai Postgres en Docker
tests/api_*.rs: aller-retour HTTP complet, une BDD de test par run, truncate entre les tests
Ne mocke pas PgPool. Utilise un vrai conteneur Postgres. Les mocks mentent sur le SQL.

Quand passer aux workspaces ?

1 service, moins de 50 routes : une seule crate (ce guide)
2 à 3 services qui partagent des modèles : workspace Cargo + crates/common
Microservices : un repo par déployable, partagés via des crates versionnées, pas des hacks de chemins

Commence en monolithe modulaire. Extrais quand les cycles de déploiement divergent, pas avant.

Le template complet avec cette structure, le Dockerfile et la CI GitHub est dans ma newsletter gratuite.

Construire une API REST performante en Rust avec Axum et Postgres

2026-02-01T00:00:00+00:00

Oublie les tutos jouets de type “hello world”. Voici comment construire une API REST prête pour la production en Rust avec Axum + SQLx + Postgres, la stack que je recommande à chaque équipe backend en 2026.

Au programme : routing propre, state partagé, JSON validé, erreurs correctes, logs structurés, pool de connexions et migrations.

Pourquoi Axum ?

Construit sur Tokio + Tower + Hyper : des middlewares matures et composables
Système d’extracteurs (State, Json, Path, Query) : moins de boilerplate qu’Actix
Tests faciles, OpenAPI facile via utoipa ou aide

Si tu viens d’Express, FastAPI ou du chi de Go, Axum te semblera familier, avec la sécurité de Rust en plus.

1. Setup du projet

cargo new rust-tasks-api && cd rust-tasks-api
cargo add axum tokio -F full serde -F derive serde_json
cargo add sqlx -F runtime-tokio,postgres,macros,migrate
cargo add tracing tracing-subscriber tower tower-http validator -F derive
cargo add thiserror anyhow uuid -F v4,serde dotenvy

L’essentiel du Cargo.toml : axum 0.7, tokio 1.x, sqlx 0.8, tower-http pour CORS, trace et compression.

2. Une architecture qui tient la charge

src/
  main.rs        # câblage : config, pool, router, serve
  config.rs      # config d'env
  db.rs          # PgPool
  error.rs       # AppError -> HTTP
  state.rs       # AppState
  routes/
    mod.rs
    tasks.rs     # handlers
    health.rs
  models/
    task.rs

Règle : des handlers fins. La logique métier vit dans des fonctions qui prennent &PgPool et renvoient Result<T, AppError>. Tu me remercieras à 50 routes.

3. State et pool

// state.rs
use sqlx::PgPool;

#[derive(Clone)]
pub struct AppState {
    pub db: PgPool,
}

// db.rs
use sqlx::postgres::{PgPoolOptions, PgPool};

pub async fn connect(url: &str) -> anyhow::Result<PgPool> {
    let pool = PgPoolOptions::new()
        .max_connections(20)
        .min_connections(2)
        .acquire_timeout(std::time::Duration::from_secs(3))
        .connect(url).await?;
    sqlx::migrate!("./migrations").run(&pool).await?;
    Ok(pool)
}

Pourquoi max_connections(20) ? Commence petit. Postgres déteste 200 connexions inactives. Scale avec PgBouncer plus tard, pas avec un pool géant.

4. Des erreurs bien gérées

// error.rs
use axum::{http::StatusCode, response::{IntoResponse, Response}, Json};
use serde_json::json;

#[derive(Debug, thiserror::Error)]
pub enum AppError {
    #[error("not found")]
    NotFound,
    #[error("bad request: {0}")]
    BadRequest(String),
    #[error(transparent)]
    Db(#[from] sqlx::Error),
}

impl IntoResponse for AppError {
    fn into_response(self) -> Response {
        let (status, msg) = match &self {
            AppError::NotFound => (StatusCode::NOT_FOUND, self.to_string()),
            AppError::BadRequest(_) => (StatusCode::BAD_REQUEST, self.to_string()),
            AppError::Db(_) => (StatusCode::INTERNAL_SERVER_ERROR, "internal error".into()),
        };
        tracing::error!(error = ?self, "request failed");
        (status, Json(json!({ "error": msg }))).into_response()
    }
}

Ne expose jamais les détails de sqlx::Error aux clients. Loggue l’erreur complète, renvoie une 500 générique.

5. Handlers : du CRUD avec validation

// models/task.rs
use serde::{Deserialize, Serialize};
use uuid::Uuid;
use validator::Validate;

#[derive(Serialize, sqlx::FromRow)]
pub struct Task { pub id: Uuid, pub title: String, pub done: bool }

#[derive(Deserialize, Validate)]
pub struct CreateTask {
    #[validate(length(min = 1, max = 200))]
    pub title: String,
}

// routes/tasks.rs
use axum::{extract::{Path, State}, Json};
use uuid::Uuid;
use crate::{state::AppState, error::AppError, models::task::*};

pub async fn create_task(
    State(s): State<AppState>,
    Json(input): Json<CreateTask>,
) -> Result<(axum::http::StatusCode, Json<Task>), AppError> {
    use validator::Validate;
    input.validate().map_err(|e| AppError::BadRequest(e.to_string()))?;
    let task = sqlx::query_as!(
        Task,
        "INSERT INTO tasks (id, title, done) VALUES ($1, $2, false) RETURNING id, title, done",
        Uuid::new_v4(), input.title
    ).fetch_one(&s.db).await?;
    Ok((axum::http::StatusCode::CREATED, Json(task)))
}

pub async fn get_task(
    State(s): State<AppState>,
    Path(id): Path<Uuid>,
) -> Result<Json<Task>, AppError> {
    let task = sqlx::query_as!(Task, "SELECT id, title, done FROM tasks WHERE id=$1", id)
        .fetch_optional(&s.db).await?
        .ok_or(AppError::NotFound)?;
    Ok(Json(task))
}

Avec les macros query_as! et query!, ton SQL est vérifié à la compilation. Les fautes de frappe sont caught avant la CI.

6. Router et middlewares

// main.rs (extrait)
use axum::{routing::{get, post}, Router};
use tower_http::{trace::TraceLayer, cors::CorsLayer, compression::CompressionLayer};
use std::net::SocketAddr;

let app = Router::new()
    .route("/health", get(health))
    .route("/tasks", post(create_task).get(list_tasks))
    .route("/tasks/:id", get(get_task))
    .layer(TraceLayer::new_for_http())
    .layer(CompressionLayer::new())
    .layer(CorsLayer::permissive())
    .with_state(state);

let addr = SocketAddr::from(([0, 0, 0, 0], 8080));
axum::serve(tokio::net::TcpListener::bind(addr).await?, app).await?;

Ajoute TraceLayer dès le premier jour. Débugger la prod sans trace_id ni logs structurés, c’est l’enfer.

7. Benchmark rapide

oha -c 100 -z 20s http://localhost:8080/health
# Attends-toi à 30k-60k rps sur health, 5k-15k rps sur un SELECT Postgres simple, sur un laptop

Si tu es sous 2k rps sur des lectures triviales, vérifie : taille du pool, index manquant, allocs JSON, build debug (utilise --release !).

Prochaines étapes

Ajoute l’auth : JWT via jsonwebtoken + axum-login, ou clés API en Postgres
Ajoute OpenAPI : utoipa + Swagger UI en 30 lignes
Déploie pas cher : voir Héberger une API Rust sur Hetzner pour 6 €/mois
Réduis la latence de queue : voir Comment j’ai réduit la p99 de 60 %

🚀 Tu veux le starter complet ? Récupère mon template Axum gratuit (cette structure + Dockerfile + CI + migrations) dans la newsletter. La Roadmap payante va 10x plus loin : tests, auth, observabilité, déploiement.

Cours vidéo Axum en production (liste d'attente)

2026-01-11T00:00:00+00:00

Cours vidéo Axum en production (bientôt, 149 €)

Un cours vidéo en français, axé code : construire une vraie API de cargo new jusqu’à la prod en HTTPS, avec tests, observabilité et tuning p99.

Programme (brouillon)

Bases Axum : routing, extracteurs, state
Postgres + SQLx : migrations, transactions, pooling
Auth : JWT et clés API, middleware
Erreurs, validation et OpenAPI
Tests : unitaires et intégration avec une vraie BDD
Observabilité : tracing, métriques, dashboards
Déploiement : Docker, Caddy, Hetzner, CI
Performance : playbook p99 et tests de charge

Prix

Early-bird (liste d’attente) : 99 €
Lancement : 149 €
Équipe (5 places) : 499 €

👉 Rejoindre la liste d’attente : abonne-toi à la newsletter avec l’objet « AXUM ». Je lance le cours quand 500 devs sont inscrits, pas de cours fantôme avec 12 élèves.

Roadmap Rust Backend 2026 : de junior à embauché

2026-01-10T00:00:00+00:00

Roadmap Rust Backend 2026 (49 €)

Arrête de sauter de tuto en tuto. Un chemin étape par étape, des bases Rust au poste de dev backend, avec projets, checklists et prépa entretiens.

Pour qui

Devs backend (Go/Python/Node) qui passent à Rust
Débutants Rust bloqués après le Book
Candidats qui visent des postes backend et système

Contenu

Un parcours en 6 étapes : Rust de base, Axum, Postgres/SQLx, Tokio, tests, déploiement et entretiens
4 projets portfolio (API de tâches, service d’auth, worker d’ingestion, tableau temps réel)
Checklists prod, p99, Docker et CI
Un pack d’entretien avec 60 questions et réponses (ownership en entretien, Tokio, SQL, system design en Rust)
Notion + PDF + mises à jour à vie

Prix

49 € en une fois. Mises à jour gratuites pour l’édition 2026. Remboursé sous 14 jours, sans question.

👉 Acheter : TODO, connecter un lien Gumroad ou Lemon Squeezy ici. Commence par une liste d’attente via la newsletter pour valider la demande avant de construire le PDF complet.

Astuce : prévente à 29 € pour les 100 premiers abonnés, puis 49 €. Rareté et boucle de retours.

FAQ

C’est un cours vidéo ? Non : du texte, du code et des checklists. Plus rapide à mettre à jour, plus facile à consulter. Le cours vidéo est à part (cours Axum).

Combien de temps ? 8 à 12 semaines à 5h/semaine si tu fais les projets.

Remboursement ? 14 jours, un email, c’est réglé.

Freelance : expert Rust backend

2026-01-04T00:00:00+00:00

Freelance Rust backend 🦀

Missions freelance uniquement, pas de mentoring d’équipe. Le moyen le plus rapide pour moi de monétiser ce blog, et pour toi de sécuriser Rust en prod.

Je t’aide sur :

Audits d’architecture Axum : structure projet, erreurs, state, auth
Audits performance : latence p99, tuning Tokio, pooling, requêtes N+1, allocs JSON
Revues Postgres : schéma, index, migrations (sqlx / refinery), pooling
Migrations : roadmap Go / Node / Python vers Rust plus un service pilote

Formules

Revue de code express (490 €)

Revue async de ton repo Axum, rapport de 10 à 15 pages plus vidéo Loom, sous 5 jours.

Sprint performance (1 900 €)

Une semaine, profiling plus correctifs p99, benchmarks avant/après inclus.

Build sur mesure (prix fixe)

Un microservice pilote, cadré et au forfait. Tu repars avec un repo à toi plus un appel de passation.

Pourquoi moi ?

J’écris des guides prod pratiques avec du code reproductible, pas de la théorie. Tu as la même rigueur sur ton code.

Contact

Email : hello@rustbackendlab.com (TODO : remplacer) avec : accès repo ou doc d’archi, contexte p99 et infra, objectif et deadline.

En ce moment : 2 créneaux par mois. Les abonnés de la newsletter sont prioritaires.

Sponsoriser Rust Backend Lab

2026-01-03T00:00:00+00:00

Sponsoriser Rust Backend Lab 🦀

Touchez une audience ultra ciblée : des devs Rust backend francophones, seniors, CTO de startups. Des gens qui achètent de l’hébergement, des outils et des formations.

Audience

Devs backend et système
Utilisateurs Axum / Tokio / Postgres
CTO de startups qui évaluent Rust
Seniors avec du pouvoir d’achat

Sponsors idéaux : hébergeurs (Hetzner, Fly.io, Shuttle), observabilité, outils dev, cloud/SaaS, plateformes de cours, job boards.

Formats

Format	Contenu	Idéal pour
Sponsor d’article	Intro de 80 mots + logo	Lancement / notoriété
Mise en avant newsletter	Section dédiée, 150 mots	Conversions
Intégration tuto	Vrai usage de ton produit dans du code	Confiance + activation
Offre d’emploi	Postes Rust backend	Recrutement

Règles

Uniquement des produits que j’utiliserais moi-même
Contenu sponsorisé toujours signalé
Pas de casinos crypto, SEO douteux ou pubs génériques
Affiliation + sponsor cumulables si pertinent

Contact

Email : sponsor@rustbackendlab.com (TODO : remplacer)

Précise : produit, URL cible, budget, planning. Je réponds sous 48h avec le kit média et des captures de trafic.

Peu de trafic mais hyper ciblé ? Oui, c’est le principe. 1 000 devs Rust backend valent mieux que 50 000 lecteurs généralistes pour un outil dev B2B.

Stats actuelles (à mettre à jour chaque mois) : visiteurs mensuels : TODO, abonnés newsletter : TODO, top articles : guide Axum+Postgres, latence p99, Rust vs Go.

Newsletter : la checklist Rust Backend Prod gratuite

2026-01-02T00:00:00+00:00

Reçois la checklist Rust Backend Prod gratuite

Un email pratique par semaine pour les devs backend. Zéro blabla.

Ce que tu reçois tout de suite :

✅ Template de projet Axum (routes, state, erreurs, tracing)
✅ Checklist Postgres prod (pooling, migrations, index)
✅ Checklist latence p99 (les 12 correctifs qui comptent vraiment)
✅ Questions d’entretien Rust backend (Axum + Tokio + SQL)

Chaque semaine :

Un vrai pattern backend en Rust (avec du code)
Un benchmark ou un retour de prod
Un outil ou une crate à connaître

👉 Inscription : remplace l’URL du formulaire dans config.toml (extra.newsletter_provider_url) par ton lien Buttondown / ConvertKit / Beehiiv, puis redéploie.

Recommandé : Buttondown (simple, pas cher) ou ConvertKit (mieux pour automatiser la vente de cours).

Pourquoi s’inscrire ?

Le trafic Google est volatile. L’email ne l’est pas. Je mets mes meilleurs conseils prod dans la newsletter en premier, le blog récupère la version publique ensuite.

Zéro spam. Désinscription en un clic. Je ne vends jamais ton email.

À propos

2026-01-01T00:00:00+00:00

À propos de Rust Backend Lab

Rust Backend Lab est une publication de niche pour les devs backend qui mettent Rust en production.

On se concentre sur un seul sujet : les backends web Rust avec Axum + Postgres + Tokio. Architecture, performance, déploiement. Pas d’articles génériques sur “c’est quoi l’ownership”.

Pour qui

Devs backend (Rust, Go, Python, Node) qui passent à Rust
Devs système qui ont besoin d’API HTTP qui tiennent la charge
Devs seniors et CTO de startups qui évaluent Rust
Entreprises qui recrutent des devs Rust backend

Ce que tu y trouves

De vraies structures de projet (pas des snippets de 50 lignes)
Des benchmarks avec méthodologie, pas du marketing
Des patterns Postgres : pooling, migrations, transactions
Des playbooks latence p99
De l’hébergement prod pas cher (6 à 12 €/mois)

Qui écrit ici ?

Je suis dev backend, je travaille tous les jours avec Rust, Postgres et le cloud. J’écris les guides que j’aurais voulu lire quand j’ai migré des services Go/Node vers Rust.

Modèle économique (transparent)

Ce blog est une activité :

Articles gratuits → liste email
Produits payants (roadmap, cours vidéo, templates)
Sponsors (outils dev, hébergeurs)
Liens affiliés (Hetzner, DigitalOcean), toujours signalés
Freelance : audits et revues de code

Travailler ensemble ? Voir Sponsors ou Freelance.

Rust Backend Lab

L'auth JWT dans Axum comme il faut : login, refresh, middleware

Le modèle de tokens : accès stateless, refresh stocké

Le piège du localStorage pour les SPA

Dépendances et schéma Postgres

State applicatif, claims et helpers de tokens

Login : argon2 et émission

Rotation du refresh dans une transaction

Middleware d’auth et extracteur AuthUser

Logout

Câblage du router

Checklist prod

Héberger un microservice Rust sur Hetzner pour 6 €/mois (Docker + CI)

Pourquoi Hetzner ?

1. Dockerfile (multi-stage, minuscule)

2. Compose et Caddy (TLS en 5 min)

3. Déploiement CI (GitHub Actions)

4. Postgres : où ?

Détail des coûts

Checklist de durcissement

Comment j'ai réduit la latence p99 de 60 % sur un service Rust

0. Mesure la p99, pas la moyenne

Correctif 1 : pool et index manquant (moins 35 % de p99)

Correctif 2 : requêtes N+1 (moins 15 % de p99)

Correctif 3 : allocs JSON sur le chemin chaud (moins 10 % de p99)

Correctif 4 : coût du tracing et des logs (moins 8 % de p99)

Correctif 5 : timeouts et dégradation gracieuse (le reste)

Checklist (à voler)

Les meilleures crates Rust pour une API en 2026

Cœur

Données

Plomberie HTTP

Observabilité

Robustesse

Mon extrait Cargo par défaut

Ce que j’évite (pour des API)

Rust vs Go pour les microservices en 2026 : les vrais tradeoffs

En deux mots

Où Rust gagne

Où Go gagne

Ma règle

Une tactique de migration qui marche

Verdict

Structurer un projet web Rust (une archi Axum propre qui scale)

Le problème du main.rs fourre-tout

La structure

main.rs reste bête

Les services se testent

Erreurs : un seul enum

Config : typée, échec au démarrage

Stratégie de tests

Quand passer aux workspaces ?

Construire une API REST performante en Rust avec Axum et Postgres

Pourquoi Axum ?

1. Setup du projet

2. Une architecture qui tient la charge

3. State et pool

4. Des erreurs bien gérées

5. Handlers : du CRUD avec validation

6. Router et middlewares

7. Benchmark rapide

Prochaines étapes

Cours vidéo Axum en production (liste d'attente)

Cours vidéo Axum en production (bientôt, 149 €)

Programme (brouillon)

Prix

Roadmap Rust Backend 2026 : de junior à embauché

Roadmap Rust Backend 2026 (49 €)

Pour qui

Contenu

Prix

FAQ

Freelance : expert Rust backend

Freelance Rust backend 🦀

Je t’aide sur :

Formules

Revue de code express (490 €)

Sprint performance (1 900 €)

Build sur mesure (prix fixe)

Pourquoi moi ?

Middleware d’auth et extracteur `AuthUser`