jainikbhandari/resumeiq

1. Overall shape

ResumeIQ is a two-tier MERN application: a React/Vite single-page app in client/ talks to an Express API in server/, and the backend persists users and resume reports in MongoDB Atlas. The frontend and backend are deployed separately, so the main architecture boundary is the REST API.

2. Frontend entry and shell

The client boots from main.jsx, renders App.jsx, and uses React Router to switch between public pages and authenticated dashboard pages. The page set includes login/register/reset-password flows plus the protected product areas: upload, result, dashboard, and history.

3. Frontend state and auth boundary

Authentication is centralized in context/AuthContext.jsx plus the useAuth hook, with route gating handled by ProtectedRoute.jsx. This is the client-side boundary that decides whether a user can enter the dashboard/history/result surfaces or must be redirected to login.

4. Client API layer

All backend communication is funneled through the small API layer in src/api/axios.js and src/api/config.js. That keeps the UI components and pages separated from backend URLs and request wiring, which matters for the diagram as the client does not directly embed business logic.

5. Public auth flows

The auth pages (Login, Register, ForgotPassword, ResetPassword) use the auth API to create accounts, sign users in, support Google login, and run password reset email/token flows. GoogleAuthButton is the client entry point for OAuth login, while auth.js in utils likely provides token/session helpers.

6. Resume upload and analysis flow

The main product flow starts on UploadResume.jsx: the user submits a PDF and optional job/role context. The backend accepts the multipart upload, extracts PDF text, scores the resume, runs Gemini-based analysis, generates interview questions and job-match insights, then returns a structured report that is shown in Result.jsx and persisted for history.

7. Backend request pipeline

server/app.js is the composition root: it connects Express routes, database initialization, middleware, and likely CORS/body parsing. Requests are split into authRoutes.js and resumeRoutes.js, with authMiddleware.js protecting all user-specific resume endpoints and uploadMiddleware.js handling PDF file ingestion.

8. Backend domain controllers

controllers/authController.js owns registration, login, Google token verification, profile lookup, forgot/reset password, and JWT issuance. controllers/resumeController.js owns upload, analysis orchestration, history retrieval, single-report fetch, and deletion. This is the main separation between identity logic and resume-processing logic.

9. Processing and AI services

The resume analysis pipeline is decomposed into service-like utilities: utils/atsScoring.js for deterministic ATS-style scoring, utils/gemini.js for LLM-generated analysis, and utils/sendEmail.js for password-reset mail. This separation keeps the controller layer thin and makes the AI/scoring logic reusable across requests.

10. Persistence model

MongoDB is modeled with models/User.js and models/Resume.js. User records support authentication and recovery data, while resume records store per-user analysis results so the history page can list, reopen, and delete previous reports independently for each account.

11. User-facing dashboard features

The dashboard area is composed from reusable UI pieces such as Navbar, AppLoader, and GoogleAuthButton, plus pages for Dashboard, History, and Result. The app also includes accessibility and usability features like read-aloud, report PDF download, light/dark mode, and mobile bottom navigation, all driven from the frontend layer.

12. External services and deployment

The backend depends on MongoDB Atlas, Google OAuth, Gemini API, and SMTP email delivery; the frontend is a static SPA hosted on Vercel, and the API is hosted on Render. Environment variables are therefore a critical architectural boundary: the client only needs the API base URL and Google client ID, while the server owns database, JWT, Gemini, OAuth, and email secrets.

13. Data flow summary

The typical end-to-end path is: browser login/session state → protected dashboard → PDF upload to Express → auth/file middleware → PDF text extraction and scoring/LLM analysis → MongoDB persistence → response rendering in the client → optional history lookup, deletion, or report download. That’s the key flow an architecture diagram should emphasize.