Stockage de fichiers avec 4 backends

Chaque application web finit par avoir besoin de stocker des fichiers. Avatars utilisateurs, rapports PDF, tableurs téléversés, scans de factures -- la liste s'allonge vite. Et dès que vous avez besoin de stockage de fichiers, vous faites face à une décision qui vous hantera pendant des années : où vont les fichiers ?

Stockez-les sur le système de fichiers local et vous ne pouvez pas scaler horizontalement. Stockez-les sur S3 et vous êtes verrouillé sur la tarification AWS. Stockez-les sur Google Cloud et vos clients européens s'inquiètent de la résidence des données. Chaque choix a des compromis, et changer plus tard signifie réécrire toute votre couche de stockage.

FLIN élimine cette décision. Vous configurez un backend de stockage en une ligne, et tout le système de fichiers -- téléversements, téléchargements, déduplication, URL signées, aperçus, compression -- fonctionne de manière identique quel que soit l'endroit où les octets vivent physiquement. Quatre backends, une API, zéro douleur de migration.

Stockage adressable par contenu

FLIN utilise le stockage adressable par contenu (CAS) : les fichiers sont identifiés par leur hash SHA-256, pas par leur nom de fichier ou chemin. Quand vous sauvegardez un fichier, FLIN calcule son hash SHA-256 et stocke le contenu sous ce hash. La déduplication automatique est gratuite -- si deux utilisateurs téléversent le même fichier, le hash est identique et FLIN ne stocke qu'une seule copie.

Les quatre backends

Backend local Le backend par défaut, ne nécessite aucun service externe. Production-ready pour les applications mono-serveur.

Backend S3 Stocke les fichiers sur Amazon S3 ou tout service compatible S3 (MinIO, DigitalOcean Spaces, Backblaze B2).

Backend Cloudflare R2 Compatible S3 mais sans frais de sortie. Peut réduire les coûts de stockage d'un ordre de grandeur.

Backend Google Cloud Storage L'option entreprise. S'intègre avec l'IAM de Google, supporte le contrôle d'accès fin et la réplication multi-région.

L'expérience développeur

Du point de vue du développeur FLIN, aucune complexité du backend n'est visible :

flinentity Invoice {
    client: text
    pdf: file
    amount: money
}

// Téléversement
route POST "/invoices" {
    validate {
        client: text @required
        pdf: file @required @document @max_size("10MB")
    }

    invoice = Invoice.create({
        client: body.client,
        pdf: body.pdf,
        amount: body.amount
    })
    save invoice

    respond { id: invoice.id, url: invoice.pdf.url }
}

// Servir avec URL signée
route GET "/invoices/:id/download" {
    invoice = Invoice.find(params.id)
    url = file_signed_url(invoice.pdf, 30.minutes)
    redirect url
}

Ce code fonctionne de manière identique sur le stockage local, S3, R2 et GCS. Vous migrez du local à R2 en changeant une ligne dans flin.config.

Ceci est la partie 126 de la série « Comment nous avons construit FLIN », documentant comment un CEO à Abidjan et un CTO IA ont conçu et construit un langage de programmation à partir de zéro.

Navigation de la série : - [125] Analytique de recherche et mise en cache des résultats - [126] Stockage de fichiers avec 4 backends (vous êtes ici) - [127] Le patron de trait StorageBackend