L'abstraction de stockage comptait plus que S3

Documents, photos, images de galerie, photos du personnel — un vrai volume de fichiers uploadés par les utilisateurs. Les stocker sur le disque du serveur applicatif crée de vrais problèmes à l'échelle : le disque se remplit, les sauvegardes deviennent énormes et lentes, la mise à l'échelle horizontale implique que chaque instance ait accès aux mêmes fichiers, et une panne serveur risque de les perdre à moins que les sauvegardes au niveau disque ne soient parfaites. Le stockage objet règle tout ça — effectivement illimité, durable par conception, naturellement partagé entre toutes les instances back-end.

Deux pièces : client-s3 est le SDK pour uploader, télécharger et supprimer. s3-request-presigner génère des URL signées à durée limitée qui laissent un client uploader ou télécharger directement vers ou depuis le stockage, le fichier ne passant jamais par le back-end.

const command = new PutObjectCommand({ Bucket, Key: storageKey });
const uploadUrl = await getSignedUrl(s3Client, command, { expiresIn: 900 });

C'est le plus important pour les gros fichiers — router un gros upload par le back-end fait de la bande passante et de la mémoire de ce serveur le goulet d'étranglement de chaque upload. Une URL présignée laisse le client parler directement au stockage ; le seul rôle du back-end est de générer le bon de permission signé.

L'abstraction est la vraie leçon

storage_provider est une simple colonne de chaîne, et core/storage/ enveloppe tout accès au stockage derrière une interface plutôt que chaque module n'appelle le SDK directement. C'est ça qui paie — si le back-end de stockage change un jour (un autre fournisseur, une exigence locale/on-prem pour la conformité), ce changement reste contenu dans un module, pas un chercher-remplacer partout où un fichier est touché.

Une somme de contrôle à côté de la clé de stockage permet au système de vérifier l'intégrité indépendamment de la confiance dans le fournisseur, et de détecter les uploads en double. metadata_json contient les métadonnées par fichier qui varient selon le type de document, sans une nouvelle colonne pour chaque attribut possible.

Les documents ont par défaut is_private: true — tout fichier uploadé ne devrait pas être lisible via une URL devinable. L'accès aux documents privés passe par le back-end, qui vérifie que le demandeur a réellement la permission de voir ce document précis, plutôt que de se reposer sur le fait que l'URL soit simplement difficile à deviner. Une URL non-devinable-mais-publique n'est pas du contrôle d'accès — et cette distinction compte beaucoup pour un système qui traite les documents personnels des gens.