api/ Express backend is a 22-line stub — no real auth, no DB, no design CRUD #83

New issue

Closed

opened 2026-09-14 04:38:41 +00:00 by Mark · 0 comments

Mark commented

2026-09-14 04:38:41 +00:00

Owner

Where: api/src/index.ts (22 lines total).

Bug:

The only real route is GET /health (index.ts:7-9).
The only other route is POST /api/v1/auth/register (index.ts:11-13) which unconditionally returns { status: 'ok' } with no body parsing, no validation, no user creation, no password hashing.
None of these declared dependencies are imported or used: cors, helmet, jsonwebtoken, multer, pg, drizzle-orm, bcrypt, @aws-sdk/client-s3, @aws-sdk/s3-request-presigner, winston, zod.
The frontend never calls the API: grep -rn 'axios|/api/v1|fetch.*api' src/ returns nothing.
Docker compose wires no api container. The CI smoke test only hits the nginx /healthz (.forgejo/workflows/ci.yml:73), never api/src/index.ts.

Why this matters:

README.md:58 claims api/ is the "Express backend (design persistence, auth stub, drizzle schema)". The "auth stub" framing suggests this is deliberate — but a 201 on a no-op auth endpoint is misleading enough that any client code that calls it gets a green light for a session that doesn't exist.
Implementation issue #4 ("Add backend API for design persistence") is triage-approved walking in Phase C per IMPLEMENTATION_PLAN.md:23. That work has not landed.
The frontend uses localStorage for persistence (src/components/gallery/data.ts:16-19). That's fine for a single-device install but breaks across browsers/devices, which is the whole point of the API.

Fix consistent with existing patterns:
Two paths, both grounded in what's already in the repo:

Wire the stub to a working contract (if #4 is meant to be in-flight):
- Use the existing api/src/db/schema.ts (3 tables: users, designs, exports).
- Use the existing multer dep for design-file uploads.
- Use the existing zod dep for input validation.
- Use the existing bcrypt + jsonwebtoken for auth (register/login → JWT in httpOnly cookie).
- Use the existing @aws-sdk/client-s3 for PES export storage in exports.pes_key.
- Add app.use(helmet()) and app.use(cors({ origin: ALLOWED_ORIGINS })) — the env var already exists at docker-compose.actors.yml:34.
- Mount routes: /api/v1/auth/{register,login,logout}, /api/v1/designs (GET list / POST create / PATCH /:id / DELETE /:id), /api/v1/designs/:id/export (POST → triggers easystitch-service export).
- Wire the frontend src/components/gallery/data.ts to fall back to API calls (token from cookie) when reachable.
Make the stub honest (if #4 is deferred):
- Remove the 201 from /api/v1/auth/register. Return 501 with { status: 'not_implemented' }.
- Update README.md:58 to remove the "auth stub" claim.
- Update IMPLEMENTATION_PLAN.md:23 to mark #4 as deferred.

Recommended: Path 2 first, fast. Then Path 1 as a single mega-issue tracked against the milestone for #4.

**Where:** `api/src/index.ts` (22 lines total). **Bug:** - The only real route is `GET /health` (index.ts:7-9). - The only other route is `POST /api/v1/auth/register` (index.ts:11-13) which unconditionally returns `{ status: 'ok' }` with no body parsing, no validation, no user creation, no password hashing. - None of these declared dependencies are imported or used: `cors`, `helmet`, `jsonwebtoken`, `multer`, `pg`, `drizzle-orm`, `bcrypt`, `@aws-sdk/client-s3`, `@aws-sdk/s3-request-presigner`, `winston`, `zod`. - The frontend never calls the API: `grep -rn 'axios|/api/v1|fetch.*api' src/` returns nothing. - Docker compose wires no api container. The CI smoke test only hits the nginx `/healthz` (`.forgejo/workflows/ci.yml:73`), never `api/src/index.ts`. **Why this matters:** - README.md:58 claims `api/` is the "Express backend (design persistence, auth stub, drizzle schema)". The "auth stub" framing suggests this is deliberate — but a 201 on a no-op auth endpoint is misleading enough that any client code that calls it gets a green light for a session that doesn't exist. - Implementation issue #4 ("Add backend API for design persistence") is `triage-approved` walking in Phase C per `IMPLEMENTATION_PLAN.md:23`. That work has not landed. - The frontend uses `localStorage` for persistence (`src/components/gallery/data.ts:16-19`). That's fine for a single-device install but breaks across browsers/devices, which is the whole point of the API. **Fix consistent with existing patterns:** Two paths, both grounded in what's already in the repo: 1. **Wire the stub to a working contract** (if #4 is meant to be in-flight): - Use the existing `api/src/db/schema.ts` (3 tables: `users`, `designs`, `exports`). - Use the existing `multer` dep for design-file uploads. - Use the existing `zod` dep for input validation. - Use the existing `bcrypt` + `jsonwebtoken` for auth (register/login → JWT in httpOnly cookie). - Use the existing `@aws-sdk/client-s3` for PES export storage in `exports.pes_key`. - Add `app.use(helmet())` and `app.use(cors({ origin: ALLOWED_ORIGINS }))` — the env var already exists at `docker-compose.actors.yml:34`. - Mount routes: `/api/v1/auth/{register,login,logout}`, `/api/v1/designs` (GET list / POST create / PATCH /:id / DELETE /:id), `/api/v1/designs/:id/export` (POST → triggers easystitch-service export). - Wire the frontend `src/components/gallery/data.ts` to fall back to API calls (token from cookie) when reachable. 2. **Make the stub honest** (if #4 is deferred): - Remove the 201 from `/api/v1/auth/register`. Return 501 with `{ status: 'not_implemented' }`. - Update README.md:58 to remove the "auth stub" claim. - Update IMPLEMENTATION_PLAN.md:23 to mark #4 as `deferred`. **Recommended:** Path 2 first, fast. Then Path 1 as a single mega-issue tracked against the milestone for #4.