PRIMUS candidate search

PRIMUS was Navigos Group’s career platform for senior professionals. It has since been discontinued. Recruiters and consultants worked in its Boolean candidate search all day: search, open a profile, load more results, go back to an earlier search.

Other developers started the React search page before I joined. It ran as a widget inside a PHP page, and every step went back to the network: results had no cache, profiles loaded on click, and numbered pages reloaded the list and jumped to the top. I worked on that page first, then rebuilt the dashboard in Angular in 2020.

Angular gave us one established setup for routing, state and UI components. The React app was spread over several packages, its state was fragmented and it felt slow in daily use. A rebuild let me fix code quality and speed together. The cache and list techniques below would also have worked in React.

Results are cached by the normalized query, so “finance and director” and “finance AND director” share one entry. Going back to a search also restores how far down the list the recruiter had loaded.

The list is virtual and requests the next 50 rows when the recruiter is 20 rows from the end. Full profiles for the rows on screen load in the background, and other sections load their code a second or more after start-up, so they open without a network wait.

I rebuilt both apps from Git, served them from one mock backend and ran the same search session five times on each, on a throttled slow 4G connection with a CPU slowed four times.

The first screen got slower. Angular showed its first result row at 11.0 s against React’s 6.7 s, and the profile prefetch sent one request per row. Today I would fetch those profiles through the batch endpoint the React app used and cancel prefetches when a new search starts.