File Storage
This is a document-exchange platform, so user-uploaded files matter a lot.
Where files live: Firebase Cloud Storage
- Clients upload directly to Firebase Cloud Storage (the app uses
firebase_storage; web/admin use the Firebase web SDK). - The API stores the resulting URLs/paths in Postgres (e.g.
resources.link,resources.cover,questions.attachments[], response images,users.profile_photo_path). - The API can delete objects via
pkg/services/cloud_storage_service.go(Firebase Admin SDKstorage.Client), using the bucket named inFIREBASE_BUCKET_NAME.
So: Postgres holds metadata + references; the bytes live in the Firebase Storage bucket
of the corresponding project (<PROD_FIREBASE_PROJECT> prod / <STAGING_FIREBASE_PROJECT>).
What gets stored
| Content | Source | DB reference |
|---|---|---|
| Resource files (manuals, PDFs) | admin/web upload | resources.link, file_type |
| Resource covers/thumbnails | admin/web upload | resources.cover |
| Question attachments | app | questions.attachments[] |
| Response images | app | response table image field |
| Profile photos | app/web | users.profile_photo_path |
To confirm — [TODO] 🔑
- [ ] Exact bucket name(s) per project (
FIREBASE_BUCKET_NAMEprod/staging). - [ ] Storage security rules (who can read/write) — are uploads authenticated?
- [ ] Folder structure / naming convention for objects.
- [ ] Lifecycle/retention and whether storage is included in Firebase backups.
- [ ] Roughly how much is stored / cost trajectory (→ 16 (private handover docs)).
- [ ] Orphan handling: when a resource/question is soft-deleted, is the file deleted from
Storage? (
cloud_storage_serviceexists — confirm it's wired into delete flows.)