brighttalent-worker
A Railway-hosted background worker that syncs and processes talent data (resumes, documents, profiles) from an external API into a database for a recruiting application.
23 commits over 1 day
What it is
This worker is the backend job processor for Bright Talent, a recruiting/talent management application. It polls a PostgreSQL database for queued jobs, fetches talent data (profiles, resumes, work history, education, skills, tags, documents) from an external API (AvoInté), extracts text from various document formats (.doc, .docx, .pdf, .rtf, images), and stores the processed data. It handles job state management (queued → running → completed/failed), progress tracking, error handling, and automatic cleanup of old jobs.
Why I built it
Built as the background processing tier for a talent management system that needed to decouple data synchronization and heavy document processing from the main Vercel-hosted frontend application. The project addresses real production challenges: improving a 30% document extraction failure rate, handling diverse file formats from applicants, suppressing noisy library warnings, and ensuring reliable job processing with retry logic and timeout protection.
Tech stack
Node.js, Prisma ORM (PostgreSQL), Railway (hosting), textract/mammoth (document text extraction), OAuth for external API integration. Includes comprehensive test suite covering API endpoints, document processing, and text extraction scenarios.
Timeline & effort
Last active Jul 22, 2025 — 23 commits across 1 active day (spanning 0 days).
Concentrated one-day sprint (23 commits on 2025-07-22) focused on setting up the worker infrastructure, implementing robust document extraction with multiple fallbacks, debugging production issues (warning suppression, PDF validation, timeout handling), and organizing the codebase. The detailed analysis docs suggest iterative refinement in response to real production logs.
Did it turn out useful?
The worker is deployed to Railway and interfaces with a production Vercel app. The documentation references production logs, real failure metrics (30% extraction failure rate across 828 documents), and active monitoring. The project includes database migrations, comprehensive error handling, health checks, and job cleanup – all markers of a live, operational system handling real user data.