Un article qui revient sur les problèmes rencontrés et les solutions apportées lors de l’unification vers S3 des uploads de logos d’entreprise et d’images de profil qui dépendaient de FileStack.
Contexte d’introduction
- Au départ, FileStack a considérablement réduit le temps nécessaire pour implémenter une « fonctionnalité d’upload non essentielle », et il a été utilisé longtemps en production sans problème
- Avec le temps, une infrastructure S3 a été mise en place, et le fait que seuls les logos/profils restent sur un service externe a commencé à poser question
- En environnement de dev/test, les limitations de débit de FileStack provoquaient fréquemment des images cassées
Problèmes
- Développer en local avec AWS S3 était peu pratique à cause de l’expiration des tokens temporaires STS, de la dépendance réseau et de la barrière à l’onboarding
- Piège qu’ils ont failli manquer pendant la migration : les logos dans les e-mails peuvent se casser plus tard à cause de l’expiration du TTL des URL présignées
Solution
- Le développement local a été simplifié avec MinIO (compatible avec l’API S3, configuration simple avec Docker)
- Pour les logos d’e-mail, le bucket reste private, tout en séparant la publication du seul chemin
public/*via CloudFront
Pourquoi l’avoir fait cette fois-ci
- Les « améliorations legacy » sont souvent repoussées à cause de la question du ROI, mais cette fois le coût des tâtonnements a baissé grâce aux outils de codage IA, ce qui a fait juger l’opération « suffisamment intéressante pour être tentée »
- Honnêtement, cela n’aurait probablement pas été tenté sans l’IA
Ce qu’ils en ont retenu
- FileStack n’était pas un mauvais choix ; à l’époque, c’était la meilleure option, et la vraie question est plutôt « quand le retirer »
- Quand la situation change, on peut le retirer, et les outils d’IA rendent ce « plus tard » beaucoup plus facile
Aucun commentaire pour le moment.