akshat-acharya/ai-driven-student-company-recommendation-system

1. This is a Next.js App Router monorepo-style web application split into three main surfaces: public marketing pages, authenticated student dashboards, and authenticated company dashboards. Route groups under app/(auth) and app/(dashboard) define the primary UI boundary, while app/api contains the backend logic.

2. The public site is lightweight and informational: landing/home, about, features, how-it-works, onboarding, and post-auth handoff pages. These pages mainly introduce the product and route users into sign-in/sign-up and role selection flows.

3. Authentication is centered on NextAuth.js with Google OAuth, exposed through app/api/auth/[...nextauth]. A separate app/api/register and app/api/user/role indicate that user creation and role assignment are handled outside the OAuth provider, likely because the system distinguishes student vs company accounts after login.

4. The dashboard layout is role-aware. app/(dashboard)/layout.tsx wraps both student and company portals, with shared chrome components such as the sidebar, navbar, logout button, theme controls, and role modal. This suggests a common authenticated shell with role-specific content inside it.

5. The student subsystem includes profile, dashboard, jobs list, job detail, recommendations, and resume pages. UI components like ApplyButton, StudentChat, resume-upload, skill-gap-card, and job-cards show that students can upload a resume, inspect parsed profile data, chat with an AI assistant, browse jobs, and apply.

6. The company subsystem mirrors that structure with dashboard, jobs list, job detail, and profile pages. Its component set is more operational: creating/editing jobs, candidate comparison, applicant review, job actions, and company chat. This is the employer-side workflow for posting roles and evaluating candidates.

7. The API layer is the main service boundary and is split by domain. Student APIs cover dashboard, jobs, profile, recommendations, chat, and apply; company APIs cover dashboard, jobs, applications, profile, compare, generate-job, re-evaluate, and chat. This clean separation makes the backend act like two coordinated domains rather than one generic CRUD surface.

8. AI functionality is isolated in lib/ai and exposed through specialized routes such as resume parsing, job generation, matching, and test endpoints. The repo explicitly uses LangChain and locally hosted Ollama models, so AI calls are treated as an internal service dependency rather than a third-party SaaS integration.

9. The AI layer is used for structured extraction and explanation, not final ranking. lib/ai/resumeParser.ts, matchScore.ts, and testModel.ts indicate three distinct concerns: turning unstructured resumes into normalized data, generating explainable match context, and validating model connectivity. The README confirms the actual recommendation score remains deterministic and rule-based.

10. The matching engine is the core product logic. It compares student profiles against job requirements using skill overlap, CGPA thresholding, experience alignment, and domain relevance. Company views also distinguish applied candidates from recommended non-applicants, so the system supports both reactive and proactive candidate discovery.

11. Persistence is handled through Prisma in prisma/schema.prisma with a long migration history, backed by Supabase PostgreSQL. This indicates the data model has evolved around auth support, role handling, student table changes, job status changes, and application workflow expansion. lib/prisma.ts is the database access boundary.

12. File upload and resume handling are separate from the main profile flow. The presence of app/api/resume/upload and app/api/resume/parse shows a staged pipeline: upload PDF, extract text, parse into structured fields, then persist into the student profile/recommendation model.

13. The app has a notable UI component library boundary. Reusable primitives live in components/ui, while domain-specific components are grouped under components/student, components/company, and components/landing. This makes the architecture easy to diagram as shared design system plus two functional portals.

14. Supporting infrastructure includes theme handling, mobile responsiveness, and route protection. providers.tsx, theme-provider, theme-toggle, use-mobile, and proxy.ts point to client-side state wrapping and request gating around authenticated routes. Static assets are minimal, so most behavior is runtime-driven through Next.js server routes and Prisma-backed persistence.