Summary
[!note] 📚 Série Smart Assets Manager
- Pourquoi l’abstraction du stockage est essentielle ← vous êtes ici
- Quatre backends de stockage, une seule interface — 27 mars
- L’API unifiée : réservation de crédits et rate limiting — 1er avril
- Stratégie de test : tests unitaires vs tests E2E — 3 avril
- Les 5 cas limites qui cassent les APIs d’images — 8 avril
- Documentation API : Swagger + Postman comme livrables — 10 avril
Et si vous aviez construit une API de génération d’images, l’aviez mise en production, et que votre premier client entreprise vous avait dit qu’il ne pouvait pas utiliser Cloudinary — sa politique de résidence des données exigeant que les images restent sur site ?
Si votre stockage est codé en dur sur Cloudinary, cette conversation clôt le contrat.
C’est ce qui s’est passé avec Smart Assets Manager — un système de génération d’images pour produire des images hero de blog, des icônes d’app store et des visuels de réseaux sociaux en masse. J’avais construit la première version avec Cloudinary comme seul backend de stockage. Dans les deux semaines suivant l’utilisation, trois cas d’usage différents sont apparus que Cloudinary ne pouvait pas satisfaire :
- Développement et tests locaux — générer des images sans avoir besoin de credentials actifs ni de payer des appels API Cloudinary
- Pipelines CI/CD automatisés — générer des images en milieu de pipeline où uploader chez un tiers crée une dépendance de données et de la latence
- Consommateurs directs de l’API — clients qui veulent les octets d’image retournés dans la réponse, pas stockés quelque part
Si votre stockage est codé en dur, chacun de ces cas devient un contournement. Si votre stockage est une abstraction, chacun devient une option de configuration.
Le Problème Central du Stockage à Backend Unique
Coder en dur un fournisseur de stockage dans votre code de génération d’images crée une dépendance qui se propage partout. Le générateur, l’endpoint API, la gestion d’erreurs, les mocks de test — tout se couple au comportement de stockage.
Changer de fournisseur plus tard signifie toucher tout ce code. Ajouter une deuxième option signifie ajouter des branches partout. Plus le système grandit, plus il se verrouille.
La couche d’abstraction résout cela avec un principe simple : le générateur ne devrait pas se soucier de l’endroit où va l’image. Il produit des octets. Quelque chose d’autre gère où ces octets finissent.
Quatre Backends Issus de l’Usage Réel
Après avoir identifié les trois cas d’usage ci-dessus (plus l’hébergement en production), le système de stockage supporte quatre backends :
| Backend | Cas d’usage | Stockage |
|---|---|---|
| Cloudinary | Hébergement en production, URLs partageables | CDN tiers |
| Système de fichiers local | Développement, exigences on-premise | Localhost ou serveur interne |
| Amazon S3 | Charges de travail en production nécessitant un stockage cloud direct | Infrastructure AWS |
| Téléchargement direct | Pipelines CI/CD, consommateurs d’API voulant les octets bruts | Aucun — base64 dans la réponse |
L’appelant spécifie quel backend utiliser dans la requête API via un paramètre storage. Le code de génération ne change pas.
Pourquoi Ce N’est Pas de la Sur-Ingénierie
La « couche d’abstraction de stockage » sonne comme un pattern qu’on ajoute pour impressionner lors d’entretiens. En pratique, c’est trois choses :
- Une classe de base abstraite avec deux méthodes :
upload()etgenerate_signed_url() - Quatre implémentations concrètes — une par backend
- Une fonction factory qui retourne la bonne implémentation en fonction du paramètre de la requête
C’est tout. Le coût est un fichier et environ 250 lignes. Le bénéfice est une flexibilité dont vous aurez définitivement besoin — parce que les décisions de stockage changent à mesure que les produits évoluent, et les décisions « juste Cloudinary » prises au lancement deviennent des « migrations coûteuses » au moment où les clients ont de vraies exigences.
Le Backend Téléchargement Direct : Celui que Personne ne Planifie
Le backend inattendu le plus utilisé était le téléchargement direct. Au lieu d’uploader l’image où que ce soit, ce backend encode en base64 les octets bruts et les retourne sous forme d’URL data directement dans la réponse API.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA...
Cela élimine entièrement le stockage externe. Pour le développement, les tests et les pipelines automatisés où l’image sera traitée ou stockée par le système aval de toute façon, c’est la bonne valeur par défaut — pas de credentials requis, pas de coûts de stockage, pas de latence d’aller-retour.
La leçon : le backend dont votre API a le plus besoin n’est pas toujours celui que vous auriez planifié d’avance. Concevez l’abstraction pour que l’ajout de nouveaux backends coûte des jours, pas des mois.
Points Clés
- Le stockage à backend unique codé en dur crée une dépendance qui se propage dans l’ensemble du système et devient coûteuse à changer.
- L’abstraction du stockage coûte un fichier (~250 lignes) et évite une migration à chaque fois que les exigences de stockage changent — ce qui arrivera.
- Le backend téléchargement direct (base64 dans la réponse) est le plus utile que personne ne planifie. Ajoutez-le par défaut.
- Le coût de l’abstraction en amont est toujours inférieur au coût de son installation rétroactive une fois le système devenu plus grand.
La Suite
Le cas architectural est fait. Dans le prochain billet : l’implémentation réelle — comment quatre backends de stockage partagent une seule interface, y compris les contrôles de confidentialité, la logique de nettoyage en cas d’échec, et l’encodage du téléchargement direct.
→ Suite : Quatre Backends de Stockage, Une Seule Interface
— Kékéli
