Three real bugs found and fixed while wiring up product images end-to-end: 1. src/prisma/migrate.ts only discovered flat prisma/migrations/<name>.sql files, never Prisma's own folder-per-migration layout (<timestamp>_<name>/migration.sql). Every migration created the normal way (via 'prisma migrate dev') was silently skipped; only a hand-added flat duplicate (prisma/migrations/0001_init.sql, now removed) ever ran. This meant schema.prisma had drifted well ahead of what any real deploy database actually had (missing columns on City, Customer, Branch, Product, several new tables). Fixed to discover both layouts; the drift is closed with a new 20260914165255_sync_schema_drift migration. 2. Neither nginx.conf (production) nor vite.config.ts (dev) proxied /uploads/ to the API — only /api/. UploadedFile/ProductImage URLs (/uploads/<file>, served by main.ts's useStaticAssets OUTSIDE the /api prefix) 404'd through both. Both now proxy /uploads/ the same way /api/ already was. 3. docker-compose.yml's api service had no volume for storage/uploads, so every uploaded file — and by extension every ProductImage row pointing at one — was lost on the next container recreate/redeploy. Added a named volume. Also: main.ts's static file serving now sets Content-Type: image/avif explicitly (serve-static's bundled mime table predates .avif and served it as application/octet-stream; browsers rendered it anyway by sniffing, but a stricter client would not have). Product photos: copied 15 real jewelry photos into the uploads volume, registered them as UploadedFile rows, and assigned each of the 5 existing Product rows a randomly picked one (duplicates allowed, per request), replacing their /img/no-items.png placeholder ProductImage row. Verified end-to-end in a real browser against the real containerized API+DB: logged in, opened the admin product list, confirmed all 5 rows render their photo (naturalWidth/Height populated, network 200s, no console errors). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
47 lines
1.6 KiB
Nginx Configuration File
47 lines
1.6 KiB
Nginx Configuration File
server {
|
|
listen 80;
|
|
server_name _;
|
|
|
|
root /usr/share/nginx/html;
|
|
index index.html;
|
|
|
|
# Docker's embedded DNS. Without re-resolving at request time, nginx caches the
|
|
# api container's IP from startup and keeps returning 502 ("no live upstreams")
|
|
# after the api container restarts with a new IP.
|
|
resolver 127.0.0.11 valid=10s ipv6=off;
|
|
|
|
location /api/ {
|
|
set $api_upstream http://goldbank-api:3000;
|
|
proxy_pass $api_upstream$request_uri;
|
|
proxy_http_version 1.1;
|
|
proxy_set_header Host $host;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
|
proxy_set_header X-Forwarded-Proto $scheme;
|
|
}
|
|
|
|
# Uploaded files (product images, category icons, ...) are served by the
|
|
# API's own static handler (main.ts useStaticAssets), not stored here —
|
|
# without this the ProductImage.url values the admin panel renders
|
|
# (/uploads/<file>) 404 through this nginx instead of reaching the API.
|
|
location /uploads/ {
|
|
set $api_upstream http://goldbank-api:3000;
|
|
proxy_pass $api_upstream$request_uri;
|
|
proxy_http_version 1.1;
|
|
proxy_set_header Host $host;
|
|
proxy_set_header X-Real-IP $remote_addr;
|
|
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
|
proxy_set_header X-Forwarded-Proto $scheme;
|
|
}
|
|
|
|
location / {
|
|
try_files $uri $uri/ /index.html;
|
|
}
|
|
|
|
location ~* \.(?:ico|css|js|gif|jpe?g|png|woff2?|eot|ttf|svg)$ {
|
|
expires 6M;
|
|
access_log off;
|
|
add_header Cache-Control "public";
|
|
}
|
|
}
|