Ein Artikel über die Probleme und den Lösungsweg bei der Zusammenführung des bislang von FileStack abhängigen Uploads von Firmenlogos und Profilbildern nach S3.
Hintergrund der Einführung
- Anfangs verkürzte FileStack die Implementierungszeit für die „nicht zum Kerngeschäft gehörende Upload-Funktion“ erheblich und lief auch in Produktion lange Zeit ohne Probleme
- Mit der Zeit stand jedoch eine S3-Infrastruktur bereit, und es begann zu stören, dass nur Logos/Profile noch bei einem externen Dienst verblieben
- In Dev- und Test-Umgebungen wurden Bilder wegen des FileStack Rate Limits häufig beschädigt angezeigt
Problem
- Die Entwicklung lokal gegen AWS S3 war umständlich wegen ablaufender temporärer STS-Tokens, Netzwerkabhängigkeit und höherer Onboarding-Hürde
- Eine Falle, die während der Migration fast übersehen worden wäre: E-Mail-Logos können später kaputtgehen, wenn die TTL der presigned URL abläuft
Lösung
- Die lokale Entwicklung wurde mit MinIO vereinfacht (S3-API-kompatibel, mit Docker einfach aufzusetzen)
- E-Mail-Logos wurden getrennt behandelt: Der Bucket bleibt private, während in CloudFront nur der Pfad
public/*öffentlich freigegeben wird
Warum gerade jetzt
- „Legacy-Verbesserungen“ werden wegen der ROI-Frage leicht aufgeschoben, aber diesmal schienen sie dank AI-Coding-Tools machbar, weil die Kosten für unnötiges Herumprobieren sanken
- Ehrlich gesagt hätte man es ohne AI wohl nicht versucht
Erkenntnisse
- FileStack war keine schlechte Entscheidung; damals war es die beste Wahl, und wichtiger ist die Frage, „wann man es wieder entfernt“
- Wenn sich die Umstände ändern, kann man es herausnehmen, und AI-Tools machen dieses „später“ deutlich einfacher
Noch keine Kommentare.