Problem
GET /api/v1/{education|experience|award|certificate|project|reference} (and generalInformation) always return the full collection for a candidate via baseGetAll / baseFindDocument (services/index.ts) — no page/limit/sort support.
Low risk for a single candidate's own CV data (bounded, personal-scale), but worth doing before this pattern gets reused anywhere with larger collections.
Proposal
- Add optional
page/limit query params to baseGetAll (candidate_profile/BaseController.ts), defaulting to returning everything if omitted (backward compatible).
- Add
.skip()/.limit() to the underlying baseFindDocument query in services/index.ts.
- Optional: basic
sort param (e.g. by startDate/createdAt).
Notes
Tracked as a known gap in TODO.md (3.6, 3.7). Lower priority than the other proposals here since current usage is low-volume per user, but flagging so it doesn't get forgotten as the product grows.
Problem
GET /api/v1/{education|experience|award|certificate|project|reference}(andgeneralInformation) always return the full collection for a candidate viabaseGetAll/baseFindDocument(services/index.ts) — nopage/limit/sortsupport.Low risk for a single candidate's own CV data (bounded, personal-scale), but worth doing before this pattern gets reused anywhere with larger collections.
Proposal
page/limitquery params tobaseGetAll(candidate_profile/BaseController.ts), defaulting to returning everything if omitted (backward compatible)..skip()/.limit()to the underlyingbaseFindDocumentquery inservices/index.ts.sortparam (e.g. bystartDate/createdAt).Notes
Tracked as a known gap in
TODO.md(3.6, 3.7). Lower priority than the other proposals here since current usage is low-volume per user, but flagging so it doesn't get forgotten as the product grows.