5 ms·
Show HN: Jobsearch – unified CLI for scraping job boards
Author here. Got tired of checking Upwork, NoFluffJobs, eFinancialCareers, LinkedIn and HN threads separately, so I built a CLI that scrapes them into a local SQLite DB and lets me browse everything in one web UI with filters and semantic search.
Details:
- Scraping via real browser over CDP (your own logged-in session, no API keys)
- Embeddings run locally (nomic-embed-text via fastembed), stored in Lance
- Rust backend, SolidJS frontend embedded in binary, single static executable
Works for my use case (Europe-based contractor). It's my first rust project, decided to do local CLI, it's helpful for me (more providers will be added, feel free to contribute).
- panpawka 2mo agoWhoa, need to check it!
- QuantFantom 2mo agoGive it a try - happy to hear feedback, especially which job boards you'd want added.
- bbxx1 2mo agonice tool
- QuantFantom 2mo agoThanks, let me know if you hit any issues using it.
- vasanthrb 2mo agoInteresting choice to require users to already be logged into the browser. Was that primarily to avoid dealing with authentication flows and anti-bot measures?
- QuantFantom 2mo agoYes. Usually if you use some website (e.g. linkedin), you are logged in. So this does not add any complexity for a user (since he already uses linkedin). At the same time, why would I complicate this and deal with login separately from user workflow. So, i would say it is practical choice. Also, obviously when user is logged-in it helps with anti-bot measures (since user might be asked to click a square or something, so he does that in his usual browser). Alternative is it do it separately from user flow (in different browser, and solve whole new set of complexities, for no real gain), e.g. in headless browser (which sucks for anti-bot). I am not really into catch your tail game of anti-bot measures, which are not static but evolve in time. If I tap into what user actually does, I have won a game, no need to re-do it forever.