How abhishekchauhannitrr/campusmeds_nitrr works
1. Overall shape
- This repo is a classic MERN split into two deployable apps: a React/Vite frontend in client/ and an Express/MongoDB API in server/.
- The frontend is mostly a role-based portal for dispensary information and operations; the backend owns all persistence, authentication, and file/email integrations.
2. Frontend entry and UI composition
- client/src/main.jsx boots the app, with App.jsx acting as the top-level router/layout coordinator.
- The UI is organized by pages under client/src/Pages and reusable components under client/src/Components, which suggests a presentation-heavy React app rather than a complex client-side state machine.
3. Page-level boundaries
- The main page boundaries are explicit: Home, Login, StockView, Student/StuDashboard, and multiple admin pages like Dashboard, Facilities, Gallery, ManageMedicine, NearbyHospitals, Records, and RegisterStudent.
- This separation maps directly to user roles and responsibilities: public browsing, student self-service, staff workflows, and admin management.
4. Role-specific workflows
- Student features are narrow: viewing a profile summary and past medical records.
- Staff features drive most write operations: creating records, registering students, managing medicine stock, facilities, hospitals, gallery, and event-like content.
- Admin extends staff capabilities with staff account management, which is a distinct privilege boundary in the app.
5. Reusable frontend building blocks
- The component structure shows strong reuse around modal-based CRUD interactions: many admin actions are handled by dedicated modal components such as add/edit/delete dialogs.
- Shared presentational pieces like Header, Footer, HomeSlider, SearchBox, Loader, GenericTable, and RunningCode support cross-page consistency.
- HomeLowerToggle/* indicates the public home page has multiple switchable informational sections rather than separate pages.
6. Backend architecture
- The API is organized by feature under server/Controllers, Routes, and Models, with a separate Middlewares/auth.js for access control.
- Each domain area has a dedicated controller/route/model pair: user, medicine, facilities, gallery, history/records, nearby hospitals, and notifications.
- server/index.js is the composition root that likely wires Express, middleware, routes, database connection, and deployment configuration.
7. Data model boundaries
- Mongoose models mirror the application’s business entities: User, Medicine, History, Facilities, Gallery, NearByHospital, and Notifications.
- This implies a document-oriented backend where the main data flow is request → controller logic → model persistence → response.
8. Authentication and authorization flow
- The app uses JWT authentication with HTTP-only cookies, plus bcrypt password hashing, as described in the README.
- auth.js is the key boundary enforcing role-based access for student/staff/admin routes, while the frontend’s role-specific pages likely depend on an authenticated session check or auto-login behavior.
9. Operational integrations
- Config/cloudinary.js indicates gallery/media uploads are stored outside MongoDB, with Cloudinary handling image persistence and delivery.
- Utils/mailSender.js plus MailTemplates/credentials.js and otpTemp.js indicate the backend sends transactional email, especially for automatically delivering student/staff credentials or verification content.
10. Record and reporting subsystem
- The History model/controller and Pages/Admin/Records components suggest a medical issuance/visit record subsystem with filtering by roll number, month, and year.
- This is one of the core data-heavy paths: staff creates records, admins/staff filter and review them, students view their own history.
11. Content management subsystem
- Facilities, nearby hospitals, gallery, and medicine stock are all managed as editable content areas rather than static pages.
- That means the application is partly a public information portal and partly an admin CMS for dispensary operational data.
12. Deployment/runtime split
- The frontend uses Vite + React and is suited for static hosting, matching the README’s Vercel deployment target.
- The backend is a Node/Express API, likely deployed separately on Render, with MongoDB as the persistent store and Cloudinary/email services as external dependencies.
13. Architectural takeaway
- The cleanest diagram is: public/browser client → React UI → Express API → MongoDB, with side channels to Cloudinary for images and email service for credentials/OTP.
- The main system boundary is role-based: public pages are read-only, while authenticated staff/admin flows write to the backend through protected routes.
Main entry points: App.jsx App · Controllers/user.js Controllers · Routes/user.js API routes · Home.jsx Public pages
Components 17
Frontend
React/Vite client UI and role-based pages.
- main.jsx · Bootstraps the client application.
client/src/main.jsx - App · Top-level routing and layout coordinator.
client/src/App.jsx - Public pages · Home and login-facing screens for public access.
client/src/Pages/Home.jsx - Student pages · Student dashboard and record viewing flows.
client/src/Pages/Student/StuDashboard.jsx - Admin pages · Admin and staff management screens.
client/src/Pages/Admin/Dashboard.jsx - Shared UI · Reusable header, footer, search, table, and loader pieces.
client/src/Components/Header.jsx - Home toggles · Switchable informational sections for the public homepage.
client/src/Components/HomeLowerToggle/About.jsx - Admin modals · Modal-based create/edit/delete interactions for admin workflows.
client/src/Components/Admin/Modal.jsx - Record views · Record-specific viewing helpers for roll lookup and detail display.
client/src/Components/Admin/Records/ViewByRoll.jsx
Backend
Express API, persistence, auth, and integrations.
- server index · Express composition root and runtime startup.
server/index.js - Auth middleware · JWT/cookie-based access control for protected routes.
server/Middlewares/auth.js - API routes · Feature routes for user, medicine, records, media, facilities, hospitals, and notifications.
server/Routes/user.js - Controllers · Domain request handlers coordinating validation and persistence.
server/Controllers/user.js - Mongo models · Mongoose entities for users, medicines, records, content, and alerts.
server/Models/User.js
External
Outside services used by the app.
- MongoDB · Primary persistent datastore for application records.
- Cloudinary · External image hosting for gallery uploads.
server/Config/cloudinary.js - Email service · Transactional email delivery for credentials and OTPs.
server/Utils/mailSender.js
Connections 19
- main.jsx → App: bootstraps · Client entry renders the app shell.
- App → Public pages: routes to · App coordinates public navigation and auth entry points.
- App → Student pages: routes to · App exposes student-specific screens after login.
- App → Admin pages: routes to · App exposes admin and staff workflows.
- Public pages → Shared UI: uses · Public pages reuse shared UI elements.
- Student pages → Record views: uses · Student views rely on record display widgets.
- Admin pages → Admin modals: uses · Admin screens are built around modal CRUD actions.
- Admin pages → Shared UI: uses · Admin pages reuse common tables, search, and layout pieces.
- Public pages → Home toggles: uses · Homepage content is split into toggleable sections.
- server index → Auth middleware: wires · Server composes middleware into protected request flow.
- server index → API routes: mounts · Entry point registers feature routes.
- API routes → Controllers: delegates · Routes forward requests into domain handlers.
- Controllers → Mongo models: persists via · Controllers use Mongoose models for CRUD operations.
- Auth middleware → API routes: protects · Middleware guards restricted API paths.
- Mongo models → MongoDB: stores in · Mongo models persist to the primary database.
- Controllers → Cloudinary: uploads media · Gallery/content flows offload images to Cloudinary.
- Controllers → Email service: sends mail · User onboarding and verification send transactional email.
- App → server index: calls API · Frontend consumes the Express backend.
- API routes → Mongo models: reads/writes · Feature routes operate over the domain schemas.