Mock vs Production Mode

The defining feature of this standalone repo is the runtime branch in routes/index.js:

const isLocal = process.env.NODE_ENV === "development";

if (isLocal) {
  auth = require("../mock/middlewares/auth");
  apiAction = require("../mock/action");
  ({ appData } = require("../mock/server"));
  ({ con } = require("../mock/routes"));
  ({ checkuseraccount, getImageFromS3 } = require("../mock/helper"));
} else {
  apiAction = require("../../actions/actions");
  ({ appData } = require("../../server"));
  ({ con } = require("../../routes/routes"));
  ({ checkuseraccount, getImageFromS3 } = require("../../helper/helper"));
}

Mode	NODE_ENV	What gets require'd	Where you can run it
Local-dev	=development	Files in mock/ (this repo)	Standalone — npm start from this repo
Production	anything else	Files from a parent someli-api checkout (../../actions/, ../../server.js, ../../routes/routes.js, ../../helper/helper.js)	Only when these files live as someli-api/dashboard/ — i.e., inside the main someli-api tree

Implication

The standalone repo can be cloned anywhere and run only in mock mode. To run it against the real database, it has to be copied into the someli-api checkout at the dashboard/ location.

This is why production runs the in-process copy: the routing file's require("../../…") paths are valid only there.

Mock files

File	Role
mock/server.js	Exports a stub appData with no real DB
mock/routes.js	Exports a stub con (the would-be sync-mysql connection) — all queries return hardcoded shapes
mock/helper.js	Exports checkuseraccount (always returns true) and getImageFromS3 (returns a placeholder image URL)
mock/action.js	Exports an apiAction class with stubbed methods
mock/middlewares/auth.js	Mounts as middleware in local-dev only; sets fake userId / accountId on res so handlers run

The mocks are simple JavaScript files; there is no msw or fixture library involved. If you need a new shape, edit the mock by hand.

Risks of this pattern

1. The two branches drift. A change to helper/helper.js in someli-api does not automatically update the local-dev mock. So the standalone can return mock data with a different shape than production gives — a footgun for FE engineers using the mock to develop against.
2. No type discipline. Without TypeScript or a schema, there's nothing forcing the mock to match production responses.
3. Boundary detection. A FE engineer running against the standalone might not realise they're in mock mode (unless they read routes/index.js). They can ship code that passes local but fails in prod.

If this repo is going to remain the dev environment for dashboard work, consider:

• Adding a banner / console.warn at startup ("RUNNING IN MOCK MODE — responses are stubbed")
• Generating mocks from real query shapes (e.g., snapshot a row and pin it as the mock return value)
• Or moving entirely to a different mock strategy (e.g., a recorded HTTP fixture played back by msw)

Implication for the documentation

This split-brain is the most novel thing about this repo. When future audits visit, the first question to ask is: "Has this repo become the source of truth, or is it still a satellite of someli-api/dashboard/?" If the latter, relationship-to-someli-api.md explains the contract.