Un artículo que resume los problemas y el proceso de solución al unificar en S3 la carga de logos de empresa e imágenes de perfil que dependían de FileStack.
Contexto de adopción
- Al principio, FileStack redujo mucho el tiempo de implementación de una “función de carga no esencial” y se usó durante mucho tiempo en producción sin problemas
- Con el tiempo, ya contaban con infraestructura en S3, y empezó a incomodar que solo los logos/perfiles siguieran en un servicio externo
- En entornos de desarrollo y pruebas, era frecuente que las imágenes se rompieran por el Rate Limit de FileStack
Problemas
- Desarrollar en local con AWS S3 resultaba incómodo por el vencimiento de tokens temporales de STS, la dependencia de red y la barrera de onboarding
- Una trampa que casi pasaron por alto durante la migración: los logos en correos podían romperse después por el vencimiento del TTL de las presigned URL
Solución
- El desarrollo local se simplificó con MinIO (compatible con la API de S3 y fácil de configurar con Docker)
- Para los logos en correos, mantuvieron el bucket como private, pero separaron la exposición publicando solo la ruta
public/*desde CloudFront
¿Por qué hacerlo ahora?
- Mejorar un “legado” suele posponerse por una cuestión de ROI, pero esta vez concluyeron que “valía la pena intentarlo” porque las herramientas de coding con IA redujeron el costo de ensayo y error
- Sinceramente, no lo habrían intentado sin IA
Lo aprendido
- FileStack no fue una mala elección; en ese momento era la mejor opción, y la pregunta más importante es “cuándo retirarlo”
- Si la situación cambia, se puede retirar, y las herramientas de IA están haciendo que ese “más adelante” sea mucho más fácil
Aún no hay comentarios.