someli-dashboard-be ↔ someli-api/dashboard/¶
Two copies of the same code¶
| Location | Role | Used by |
|---|---|---|
someli-api/dashboard/ |
In-process, production-mounted copy. Mounted onto the main Express app at /auth per someli-api/server.js. |
Production traffic. |
someli-dashboard-be/ |
Standalone repo. Runnable on port 6001 with a mock/ layer when NODE_ENV=development. |
Local development with mocks; future-extraction candidate. |
The two copies share most code but have drifted since the standalone was created.
File-by-file diff (audit-time snapshot)¶
| File | Status |
|---|---|
package.json |
(not compared — production uses someli-api's package.json) |
server.js |
Differs: production copy adds cors and app.options('*', cors()); standalone has only express-session |
conf.js |
Standalone-only (production uses someli-api/conf.js) |
routes/index.js |
Production has ~1615 extra lines — primarily a /leaderboard/:pId endpoint added after the standalone was created |
services/job_account_insights.js |
Compared — appears similar (verify) |
services/job_growth_insights.js |
Compared — appears similar (verify) |
services/job_post_insights.js |
Compared — appears similar (verify) |
mock/* |
Standalone-only (production doesn't need mocks) |
README.md |
Different: standalone has the dev/uat/main branch workflow README |
The single largest divergence is the leaderboard endpoint — present only in the production copy. New work on leaderboards (or anything that the leaderboard depends on) must edit the production copy directly, not this standalone.
What this implies¶
When you fix a bug:
| If the bug is in… | Edit | Why |
|---|---|---|
| One of the 9 GET endpoints that exist in both | Both copies (or one and a follow-up PR for the other) | Otherwise the standalone diverges further |
The /leaderboard/:pId endpoint |
The production copy in someli-api/dashboard/routes/index.js |
Standalone doesn't have it |
A helper logic in services/job_*_insights.js |
Whichever copy you're working from; verify the other after | Most likely close to identical, but verify before assuming |
Mock harness (mock/*) |
Standalone only | Production doesn't have it |
Future direction¶
Two paths are plausible:
Path A — Retire the standalone. Treat the in-process copy as the only source of truth; delete someli-dashboard-be (after moving the mock harness out to a place the main repo can use, if useful). Pro: no drift. Con: lose the ability to develop dashboard endpoints without spinning up the entire someli-api.
Path B — Promote the standalone. Extract someli-api/dashboard/ out of the main repo and into this standalone. Update someli-api/server.js to no longer mount it (or to proxy to it). Pro: cleaner separation of concerns; analytics has its own deploy unit. Con: real work — production routes change; database connection management becomes a service-boundary problem; the ../../... requires need to be replaced with a proper module structure.
The team should pick one. The current half-state is the worst-of-both: drift accumulates without anyone benefiting.
A small concrete first step toward Path B (extraction): replace the runtime require("../../...") branch in routes/index.js with a proper module structure (actions, helper, dbDriver) inside the standalone, then point someli-api/dashboard/ at the standalone's published version (or via a git submodule, or by npm link during dev).