Enterprise Readiness Assessment¶
1. Executive summary¶
Verdict: A tiny, low-risk repository that is not yet a true standalone service. It is half-extracted from someli-api, with two code copies that drift, no CI/CD of its own, no tests, and no production deploy story. Its current value is the mock/ harness for local-dev work on dashboard endpoints.
Top 3 strengths:
1. Small surface (~2K LoC) — easy to read and reason about
2. Clean separation of routes / services / mocks
3. Codebase is internally consistent with someli-api conventions (so engineers don't context-switch)
Top 5 risks:
1. Drift with someli-api/dashboard/ — the production copy already has +1615 lines (leaderboard endpoint) the standalone lacks. Risk grows over time.
2. Mock-mode is the only standalone-runnable mode — the "production" branch of routes/index.js requires ../../actions/, ../../helper/ etc. from a parent someli-api tree
3. No tests, no CI — changes propagate by manual copy
4. Auth-by-convention — handlers assume res.userId/res.accountId set upstream; standalone has none
5. Five unused npm dependencies (jsonwebtoken, crypto-js, request, node-cron, path) — pure attack surface
Top 5 recommendations:
1. Decide direction: retire the standalone, or invest in extracting it (Path B). The half-state is the worst option.
2. Prune unused dependencies
3. Replace the runtime-require("../../...") branch with a real local module structure
4. Add a /health endpoint + structured logging
5. Add minimal smoke tests (supertest + mock mode)
2. Methodology & scope¶
Audited via find, cat, diff, grep, wc against the cloned someli-gh/someli-dashboard-be/ directory. Compared against someli-api/dashboard/. No tests run (none exist).
3. Maturity assessment (CMMI 1–5)¶
| Pillar | Current | 12-mo target | Why |
|---|---|---|---|
| Architecture & Modularity | 1 | 2 | Runtime-branch require() hack; unclear standalone-vs-embedded model |
| API Contract & Versioning | 1 | 2 | No OpenAPI, no versioning, no per-handler input validation |
| Data Architecture | 2 | 2 | Same shared MySQL schema as the rest of the platform; queries are parameterised |
| Background Processing | n/a | n/a | This service has no background processing |
| Security & Compliance | 1 | 3 | Hardcoded session fallback; mock-mode is deployable; auth-by-convention |
| Observability | 1 | 3 | console.log only; no error tracking, no metrics, no health endpoint |
| Reliability & Resilience | 1 | 2 | sync-mysql blocks the event loop; no graceful shutdown; no readiness check |
| Scalability | 1 | 2 | Sync queries; no caching; aggregations run on every request |
| Testing & Quality Gates | 1 | 2 | Zero tests; no CI gate |
| CI/CD & Deployment | 1 | 3 | No standalone deploy; production runs the in-process copy |
| Infrastructure as Code | 1 | 2 | No Dockerfile, no nginx config, no PM2 ecosystem entry |
| Cost Visibility & FinOps | n/a | n/a | Negligible footprint |
| Documentation & Knowledge Management | 2 | 3 | This audit + the README cover the basics; needs OpenAPI / runbook for prod |
| Team Practices & Governance | 2 | 2 | README describes branch workflow; no PR template; no code-review checklist |
4. Findings¶
| ID | Severity | Description | Mitigation phase |
|---|---|---|---|
| F-1 | Low | Hardcoded fallback session secret "change-me" |
0a (this week) |
| F-2 | Medium | Auth-by-convention: handlers assume upstream middleware ran | 0 |
| F-3 | Low (likelihood), High (impact) | Mock auth deployable if NODE_ENV=development is leaked |
0a |
| F-4 | n/a | Inherited security posture of someli-api (see ../someli-api/security.md) |
0 |
| F-5 | Low | Five unused npm dependencies | 0a |
| F-6 | Medium | Drift between standalone and in-process copy (+1615 lines in prod) | 1 |
| F-7 | Medium | No tests; no CI; no health endpoint | 0 |
| F-8 | Low | mock/ shapes may not match production response shapes — silent divergence |
1 |
5. Strategic decisions¶
The pivotal decision is what this repo is for:
| Decision | Implication |
|---|---|
| A. Retire | Delete someli-dashboard-be. Move the mock/ harness into someli-api/dashboard/mock/ so dashboard dev still has mocks. Maintenance burden goes to zero. |
| B. Extract | Make someli-dashboard-be a real standalone service. Replace require("../../...") with local modules. Add Dockerfile, CI, deploy pipeline, auth middleware. someli-api/dashboard/ is then deleted (or thinly proxies to the standalone). |
| C. Status quo | Continue maintaining both copies in sync. Accept drift risk. The team's calendar will eventually force option A or B. |
The audit recommends A unless there is a concrete near-term need to ship the dashboard as a separate service (e.g., scaling the analytics workload independently).
6. Roadmap¶
Phase 0a — This week¶
- Prune unused dependencies (F-5)
- Throw at startup if
SESSION_SECRETis unset, or removeexpress-session(F-1) - Add a
console.warn("MOCK MODE")banner at startup whenisLocal === true(F-3 mitigation) - Add
/healthendpoint (F-7 partial)
Phase 0 — Stabilise (months 0–3)¶
- Decide A / B / C (Strategic decisions section)
- Add the F-2 auth guard
- Add structured logging (morgan + pino or winston)
- Write 5–10 smoke tests against the mock server
- Document API in OpenAPI / Markdown table
Phase 1 — Foundation (months 3–9)¶
- If A: execute retirement
- If B: extract local modules; add Dockerfile + nginx + PM2; set up CI deploy
- Reconcile mock response shapes with production responses (F-8)
Phase 2 — Modular Refactor (months 9–18)¶
- Only relevant if B was chosen. Add proper input validation (
zodorexpress-validator); migrate to async MySQL driver; add Redis caching for aggregations.
7. Risk register¶
| ID | Risk | Likelihood | Impact | Mitigation phase |
|---|---|---|---|---|
| R-1 | Drift between standalone and in-process copies causes a fix to be applied in only one place | High | Medium | Phase 1 (decision needed) |
| R-2 | Standalone gets deployed in production by mistake in mock mode | Low | High | Phase 0a (add guard) |
| R-3 | A regression in someli-api/helper/helper.js breaks the dashboard in production but not in standalone mock-mode dev |
Medium | Medium | Phase 0 (cross-test) |
| R-4 | Slow analytics query blocks the entire someli-api event loop (because sync-mysql) |
Medium | High (whole platform impact) | Phase 1 (async MySQL) |
8. Standards compliance¶
- OWASP Top 10: A04 Insecure Design (mock-mode-deployable); A05 Security Misconfiguration (fallback secret); A07 Identification & Authentication Failures (auth-by-convention)
- 12-factor: "Backing services" — partially violated (the repo can't run as a true standalone backing service); "Concurrency" — sync-mysql defeats this
9. Open questions¶
- [VERIFY] Are the three
services/job_*_insights.jsfiles in this repo byte-identical to their counterparts insomeli-api/dashboard/services/or do they drift too? (Compared briefly during audit; spot-check needed.) - [VERIFY] What is the production access path to this dashboard? (Looks like
/auth/dashboard/*throughsomeli-api, but worth confirming with the nginx config.) - [VERIFY] Are the mock response shapes actually consumed by
someli-platformduring local dev, or do developers always run against a realsomeli-api?