Este é um texto que organiza os problemas enfrentados e o processo de solução ao integrar no S3 o upload de logos da empresa/imagens de perfil, que antes dependia do FileStack.
Contexto de adoção
- No começo, o FileStack reduziu bastante o tempo de implementação de uma “funcionalidade de upload que não era central”, e foi usado por muito tempo em produção sem problemas
- Com o tempo, a infraestrutura em S3 foi sendo preparada, e começou a incomodar a ideia de apenas logos/perfis continuarem em um serviço externo
- Em ambientes de dev/teste, passou a ser frequente que imagens quebrassem por causa do Rate Limit do FileStack
Problema
- Desenvolver localmente com AWS S3 era incômodo por causa da expiração de tokens temporários do STS, dependência de rede e barreira de onboarding
- Uma armadilha que quase passou despercebida durante a migração: logos em e-mails poderiam quebrar depois por causa da expiração do TTL de URLs presigned
Solução
- O desenvolvimento local foi simplificado com MinIO (compatível com a API do S3 e fácil de configurar com Docker)
- Para logos em e-mails, o bucket foi mantido como private, separando a exposição apenas do caminho
public/*via CloudFront
Por que fazer isso agora
- “Melhorar legado” costuma sempre ser adiado por causa da questão de ROI, mas desta vez houve a percepção de que “valia tentar” porque as ferramentas de programação com IA reduziram o custo de tentativa e erro
- Sinceramente, sem IA isso provavelmente nem teria sido tentado
Lições aprendidas
- O FileStack não foi uma escolha ruim; naquela época, era a melhor opção, e a questão mais importante é “quando remover”
- Quando o contexto muda, dá para remover depois, e as ferramentas de IA estão tornando esse “depois” muito mais fácil
Ainda não há comentários.