api/ is wired into nothing — no docker service, no client calls, no CORS even if a client called #86

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

Where:

  • docker-compose.yml and docker-compose.actors.yml (search confirms: no api service is referenced).
  • src/ (grep for axios, /api/v1, fetch.*api returns nothing — frontend never calls the backend).
  • api/src/index.ts (no app.use(cors(...)), no app.use(helmet()) — both deps installed).

Bug:

  • cors and helmet are in api/package.json dependencies but never imported.
  • ALLOWED_ORIGINS env var is set at docker-compose.actors.yml:34 but no api service reads it.
  • The CI smoke test (.forgejo/workflows/ci.yml:73) hits /healthz on the nginx container, not api/src/index.ts.
  • If a frontend caller ever did hit :3001/auth/register from :3000 in dev, the browser would block the request as cross-origin and the response would never arrive.

Fix consistent with existing patterns:
Match what the easystitch-service client already does (src/lib/easystitch-client.ts:118-135 resolveBaseUrl, 137-143 getAuthHeaders). The frontend already proxies /api/easystitch through Vite in dev (vite.config.ts) and nginx in prod (docker-compose.yml:13). Mirror that for the api/ backend:

  1. In vite.config.ts, add a second proxy entry for /api/v1 → http://localhost:3001.
  2. In the production nginx config, add a location /api/v1/ block forwarding to the api upstream.
  3. In api/src/index.ts, add before the routes:
    import cors from 'cors';
    import helmet from 'helmet';
    const allowed = (process.env.ALLOWED_ORIGINS ?? 'http://localhost:3000').split(',').map(s => s.trim());
    app.use(helmet());
    app.use(cors({ origin: allowed, credentials: true }));
    
  4. In docker-compose.yml, add an api service that builds api/ and reads DATABASE_URL, ALLOWED_ORIGINS, JWT_SECRET, S3_* envs.

Acceptance: a frontend fetch to /api/v1/auth/register (after wiring the route, see #83) hits the Express app, returns either a real 201 or the honest 501 from #84, and the browser sees the response (no CORS preflight failure).

**Where:** - `docker-compose.yml` and `docker-compose.actors.yml` (search confirms: no api service is referenced). - `src/` (grep for `axios`, `/api/v1`, `fetch.*api` returns nothing — frontend never calls the backend). - `api/src/index.ts` (no `app.use(cors(...))`, no `app.use(helmet())` — both deps installed). **Bug:** - `cors` and `helmet` are in `api/package.json` dependencies but never imported. - `ALLOWED_ORIGINS` env var is set at `docker-compose.actors.yml:34` but no api service reads it. - The CI smoke test (`.forgejo/workflows/ci.yml:73`) hits `/healthz` on the nginx container, not `api/src/index.ts`. - If a frontend caller ever did hit `:3001/auth/register` from `:3000` in dev, the browser would block the request as cross-origin and the response would never arrive. **Fix consistent with existing patterns:** Match what the easystitch-service client already does (`src/lib/easystitch-client.ts:118-135` `resolveBaseUrl`, `137-143` `getAuthHeaders`). The frontend already proxies `/api/easystitch` through Vite in dev (`vite.config.ts`) and nginx in prod (`docker-compose.yml:13`). Mirror that for the api/ backend: 1. In `vite.config.ts`, add a second proxy entry for `/api/v1` → `http://localhost:3001`. 2. In the production nginx config, add a `location /api/v1/` block forwarding to the `api` upstream. 3. In `api/src/index.ts`, add before the routes: ```ts import cors from 'cors'; import helmet from 'helmet'; const allowed = (process.env.ALLOWED_ORIGINS ?? 'http://localhost:3000').split(',').map(s => s.trim()); app.use(helmet()); app.use(cors({ origin: allowed, credentials: true })); ``` 4. In `docker-compose.yml`, add an `api` service that builds `api/` and reads `DATABASE_URL`, `ALLOWED_ORIGINS`, `JWT_SECRET`, `S3_*` envs. Acceptance: a frontend fetch to `/api/v1/auth/register` (after wiring the route, see #83) hits the Express app, returns either a real 201 or the honest 501 from #84, and the browser sees the response (no CORS preflight failure).
Mark closed this issue 2026-09-14 04:54:26 +00:00
Sign in to join this conversation.
No description provided.