In questo progetto l’upload degli avatar è implementato in locale tramite filesystem, in modo semplice e coerente con i requisiti dell’assignment.
L’architettura è però progettata per permettere una migrazione verso uno storage cloud senza refactor invasivi.
- Upload gestito tramite
multer(diskStorage) - File salvati in:
uploads/avatars/
- File serviti staticamente tramite
ServeStaticModule:
GET /uploads/avatars/<filename>
- Nel database viene salvato solo il riferimento (
avatarUrl)
- Nessuna dipendenza esterna
- Setup immediato
- Ideale per demo e review tecnica
- Facilmente testabile localmente
- Sostituire
diskStoragecon uno storage custom - Delegare l’upload a un service dedicato (es.
FileStorageService) - Salvare nel DB solo l’URL pubblico restituito dallo storage
- Scalabilità
- Persistenza indipendente dall’API
- Standard industriale
Minimo.
Il controller rimane invariato, cambia solo l’implementazione dello storage.
Firebase Storage può essere usato solo come file storage, senza Firebase Authentication.
- API NestJS deployata (Render / Fly.io / Railway)
- Firebase Storage per asset statici
- Regole di sicurezza basate su:
- token JWT custom
- signed URLs
- oppure bucket pubblico (solo avatar)
- Mostra integrazione con BaaS
- Facile deploy demo
- Abilitabile come extra senza toccare il core
L’upload è volutamente isolato:
- controller → valida e riceve file
- service → aggiorna riferimento
- storage → intercambiabile
Questo consente di cambiare backend di storage senza modificare il dominio applicativo.