How tamalnath963/facultyhub works
1. Overall shape
- FacultyHub is a two-tier MERN application: a React frontend in frontend/ and an Express/MongoDB API in backend/.
- The core runtime boundary is browser UI → Axios HTTP calls → Express routes → Mongoose models → MongoDB, with file uploads handled separately on the backend filesystem.
2. Backend entry and API surface
- backend/server.js is the API bootstrap point; it wires middleware, database connection, and route modules.
- The API is split by domain into authRoutes, facultyRoutes, reviewRoutes, reportRoutes, and adminRoutes, which makes the backend naturally diagrammable as a set of feature-specific services rather than one monolith.
3. Data model boundary
- MongoDB stores four main collections: User, Faculty, Review, and Report.
- User supports all roles (student, faculty, admin) and drives access control.
- Faculty represents profile and status data.
- Review stores submitted ratings, moderation state, and review metadata.
- Report holds generated/aggregated performance output for display and export.
4. Auth and authorization flow
- Authentication is JWT-based: login/register endpoints issue tokens, and backend/middleware/auth.js protects privileged routes.
- Role checks are enforced on the server, not just in the UI, so the architecture has both presentation-layer gating and API-layer enforcement.
- The frontend keeps auth state in frontend/src/context/AuthContext.js, while ProtectedRoute.js blocks unauthenticated navigation.
5. File upload subsystem
- Profile photo upload is a separate concern handled by backend/middleware/upload.js using Multer.
- Uploaded images are stored in the backend uploads/ directory, which is a persistence boundary distinct from MongoDB.
- The frontend has a dedicated PhotoUpload page and photo-aware profile pages for student, faculty, and admin.
6. Faculty management subsystem
- Faculty CRUD and status management live in facultyRoutes.js and are surfaced in FacultyDirectory, FacultyForm, FacultyMyProfile, and SearchFaculty.
- This subsystem supports both admin-created records and faculty self-management, so ownership is role-dependent.
- The directory UI supports browsing, search, and profile inspection, while the form UI serves create/edit flows.
7. Review lifecycle and moderation
- Reviews follow a state machine: pending → approved/rejected, with only approved reviews becoming publicly visible.
- reviewRoutes.js is the moderation boundary: students can submit reviews, admins can approve/reject/delete, and faculty/students can view approved feedback.
- The frontend divides this into SubmitReview, ReviewsPage, and AdminReviews, which map cleanly to submission, display, and moderation concerns.
8. Performance reporting subsystem
- reportRoutes.js provides the reporting layer, which derives performance metrics from approved reviews rather than manual entry.
- The README indicates MongoDB aggregation is used for averages, category scores, semester comparisons, and leaderboard ranking.
- ReportsPage is the main presentation layer for charts, report cards, and export-oriented views, while the Report model represents persisted report output when needed.
9. Role-specific UI structure
- The frontend routes in App.js are organized by role and task: student, faculty, and admin each get distinct pages and dashboards.
- Sidebar.js is role-aware navigation, and Dashboard.js acts as a landing page that changes based on the current user’s role.
- Admin-focused pages (AdminDashboard, AdminReviews, Adminprofile) form a separate control plane from the general user experience.
10. Frontend composition pattern
- Reusable UI is concentrated in components/ such as FacultyCard, StarRating, Sidebar, and ProtectedRoute.
- Page-level components in pages/ orchestrate data fetching, filtering, forms, and role-specific rendering.
- Shared API access is centralized in frontend/src/utils/api.js, so all network calls are funneled through one client boundary.
11. Cross-cutting UX and state
- AuthContext.js is the main shared client state for login status, current user, and role-driven rendering.
- The app uses React Router for navigation and React-based component composition for all major screens.
- Global styling is centralized in index.css, with the README indicating a dark-theme design system built using CSS variables.
12. Key architecture boundaries to capture in a diagram
- Browser/UI boundary: React pages and components.
- Client state boundary: Auth context and protected routing.
- API boundary: Express route modules by domain.
- Security boundary: JWT middleware and role checks.
- Persistence boundary: MongoDB collections plus filesystem uploads.
- Derived-data boundary: report aggregation from review data.
13. External/runtime dependencies that materially matter
- Node.js/Express run the server side, React runs the client side, MongoDB is the primary datastore, and JWT/bcrypt/Multer support security and uploads.
- The repo is designed to be run as two processes in development, with the root package coordinating frontend and backend startup.
Main entry points: server.js Server · App.js App · api.js API Client · reviewRoutes.js Review Routes
Components 25
Frontend
React UI, shared client state, and page-level flows
- App · Top-level React routes and role-based page composition
frontend/src/App.js - Auth State · Shared login, user, and role state for the client
frontend/src/context/AuthContext.js - Protected Route · Blocks unauthenticated navigation on the client
frontend/src/components/ProtectedRoute.js - API Client · Central Axios boundary for browser-to-server calls
frontend/src/utils/api.js - Sidebar · Role-aware navigation for dashboard and feature pages
frontend/src/components/Sidebar.js - Dashboard · Role-sensitive landing page for students, faculty, and admins
frontend/src/pages/Dashboard.js - Faculty Directory · Browse, search, and inspect faculty records
frontend/src/pages/FacultyDirectory.js - Faculty Form · Create and edit faculty profiles and status data
frontend/src/pages/FacultyForm.js - Submit Review · Student review entry flow with ratings and metadata
frontend/src/pages/SubmitReview.js - Reviews Page · Public-facing approved review listings and feedback views
frontend/src/pages/ReviewsPage.js - Admin Reviews · Admin moderation UI for approving, rejecting, and deleting reviews
frontend/src/pages/AdminReviews.js - Reports Page · Charts, report cards, and export-oriented performance views
frontend/src/pages/ReportsPage.js - Photo Upload · Client flow for uploading profile images
frontend/src/pages/PhotoUpload.js
Backend
Express API, security middleware, and MongoDB models
- Server · Express bootstrap that wires middleware, database, and routes
backend/server.js - Auth Routes · Login, signup, and JWT issuance endpoints
backend/routes/authRoutes.js - Faculty Routes · Faculty CRUD and status management endpoints
backend/routes/facultyRoutes.js - Review Routes · Review submission and moderation endpoints
backend/routes/reviewRoutes.js - Report Routes · Derived reporting and aggregation endpoints
backend/routes/reportRoutes.js - Admin Routes · Admin-only control plane endpoints
backend/routes/adminRoutes.js - Auth Middleware · JWT verification and server-side role checks
backend/middleware/auth.js - Upload Middleware · Multer-based profile image handling
backend/middleware/upload.js - User · Shared account and role records for students, faculty, and admins
backend/models/User.js - Faculty · Faculty profile and status records
backend/models/Faculty.js - Review · Submitted reviews, moderation state, and metadata
backend/models/Review.js - Report · Persisted report output and aggregated metrics
backend/models/Report.js
Connections 39
- App → Auth State: uses · App reads current user and role state
- App → Protected Route: wraps · Routes are guarded at the UI boundary
- App → Sidebar: renders · Shared navigation is composed into the shell
- App → Dashboard: routes to · Role-aware landing page
- App → Faculty Directory: routes to · Faculty browsing surface
- App → Submit Review: routes to · Review submission surface
- App → Reviews Page: routes to · Review display surface
- App → Admin Reviews: routes to · Admin moderation surface
- App → Reports Page: routes to · Reporting surface
- App → Photo Upload: routes to · Profile image upload surface
- Dashboard → API Client: fetches via · Dashboard data loads through the shared client
- Faculty Directory → API Client: fetches via · Directory and search data use the shared client
- Faculty Form → API Client: writes via · Create and update requests use the shared client
- Submit Review → API Client: submits via · Review creation requests use the shared client
- Reviews Page → API Client: reads via · Approved review views load from the API
- Admin Reviews → API Client: moderates via · Admin actions call the API client
- Reports Page → API Client: queries via · Report and analytics requests use the shared client
- Photo Upload → API Client: uploads via · Photo upload requests use the shared client
- Server → Auth Routes: mounts · Authentication endpoints are registered on startup
- Server → Faculty Routes: mounts · Faculty endpoints are registered on startup
- Server → Review Routes: mounts · Review endpoints are registered on startup
- Server → Report Routes: mounts · Report endpoints are registered on startup
- Server → Admin Routes: mounts · Admin endpoints are registered on startup
- Server → Auth Middleware: uses · Protected routes rely on authentication middleware
- Server → Upload Middleware: uses · Uploads rely on file handling middleware
- Server → User: connects to · Server bootstraps database access through models
- Server → Faculty: connects to · Server bootstraps database access through models
- Server → Review: connects to · Server bootstraps database access through models
- Server → Report: connects to · Server bootstraps database access through models
- Auth Routes → User: reads/writes · Auth endpoints create and validate user accounts
- Faculty Routes → Faculty: reads/writes · Faculty endpoints manage faculty records
- Faculty Routes → Auth Middleware: protects · Role checks guard management operations
- Review Routes → Review: reads/writes · Review submission and moderation persistence
- Review Routes → User: authorizes · Review actions are tied to user roles
- Review Routes → Auth Middleware: protects · Privileged review actions require JWT auth
- Report Routes → Report: reads/writes · Persisted reporting output and summaries
- Report Routes → Review: derives from · Reports aggregate approved reviews
- Admin Routes → Auth Middleware: protects · Admin control plane is server-side gated
- Admin Routes → User: manages · Admin operations interact with user roles