33 lines
1.7 KiB
Markdown
33 lines
1.7 KiB
Markdown
# Architect — F-052
|
|
|
|
## Diagnóstico
|
|
- Las URLs de imagen de producto se almacenan como `/uploads/<uuid>.<ext>` en `catalog_product_images.url`.
|
|
- Solo el admin (`apps/admin/public/uploads/`) tiene esos archivos.
|
|
- El frontend (3003) y el storefront (3005) sirven estáticos desde sus propios `public/`, que no contienen `uploads/`.
|
|
- El backend (3000) no tiene una ruta `/uploads/` y por tanto tampoco puede servirlos.
|
|
- Resultado: `<img src="/uploads/...">` desde frontend/storefront → 404.
|
|
|
|
## Solución elegida
|
|
**Sincronizar `public/uploads/` del admin al frontend y al storefront en cada upload, y al arranque.**
|
|
|
|
Pasos:
|
|
1. Crear un helper que, ante una subida nueva en el admin (`/api/upload`), copie el archivo a `frontend/public/uploads/` y `storefront/public/uploads/` después de escribirlo.
|
|
2. Al arranque de `monolith.sh`, sincronizar los archivos existentes con `rsync` para cubrir el caso "arranque en frío sin uploads aún".
|
|
3. El backend sigue siendo solo API; no se añade ruta `/uploads/`.
|
|
|
|
Razón de no añadir ruta backend:
|
|
- Mantener el backend libre de filesystem compartido.
|
|
- Evita acoplarse a `process.cwd()` del backend, que es distinto al del admin.
|
|
- El admin es el único origen de uploads.
|
|
|
|
## Alternativas descartadas
|
|
- **Ruta `/uploads/` en el backend**: requiere cambiar `cwd` o aceptar una ruta absoluta; complica el deployment.
|
|
- **Proxy desde frontend a admin**: añade un round-trip y un puerto extra en la URL.
|
|
|
|
## Acceptance
|
|
- Tras subir una imagen desde el admin, esa imagen aparece como 200 en:
|
|
- `GET http://192.168.18.93:3003/uploads/<file>`
|
|
- `GET http://192.168.18.93:3005/uploads/<file>`
|
|
- Tras un restart del monolito, los uploads ya existentes se sincronizan.
|
|
- `next build` no falla por assets faltantes.
|