How mediwateyash/live-meet works
1. High-level shape
- This is a two-process monorepo: a React client in client/ and an Express/Mongo backend in server/.
- The product is a role-based live learning platform with three main personas: Admin, Instructor/Teacher, and Student.
2. Frontend boundary
- The frontend is a Vite app using React, React Router, TailwindCSS, and socket.io-client.
- client/src/main.jsx and App.jsx act as the app entry/routing shell.
- The UI is split into reusable layout and primitive components under components/, with role-specific pages under pages/.
3. Frontend navigation and layout
- Layout components (Navbar, Footer, PageLayout, StudentLayout) separate public, authenticated, and student-focused shells.
- Page folders map directly to product areas:
- pages/public for marketing/browse/detail views
- pages/auth for login/register/reset flows
- pages/admin, pages/instructor, pages/student for role dashboards and workflows
4. Frontend data access layer
- The src/api/ folder is the client’s service boundary to the backend.
- Separate API modules exist by domain: auth, users, courses, instructor, admin, liveLectures, notifications, and progress.
- axios.js is the shared HTTP client, so all server interaction is centralized there rather than embedded throughout pages.
5. Frontend state and cross-cutting concerns
- Global state is organized in src/store/ with distinct stores for auth, course, and ui.
- Custom hooks like useAuth and useDebounce handle auth-derived behavior and search/filter UX.
- Shared UI atoms such as buttons, modals, badges, progress bars, skeletons, and notification bell support consistent interaction patterns across role dashboards.
6. Backend request layer
- The server is an Express app (server/index.js) with route modules aligned to business domains: auth, user, course, admin, instructor, liveLecture, notification, and progress.
- Each route delegates to a controller module, so routing is thin and business logic lives in controllers.
7. Backend security and access control
- Authentication is JWT-based (utils/generateToken.js) and enforced through middleware/auth.js.
- Role authorization is separated into middleware/role.js, which is the key boundary for Admin vs Instructor vs Student access.
- This role gate is what makes the same backend serve different dashboards and capabilities.
8. Backend domain model
- MongoDB/Mongoose models represent the core data graph:
- User
- Course
- Review
- Progress
- Notification
- LiveLecture
- InstructorRequest
- These models define the persistent state for enrollment, content, live sessions, notifications, and instructor onboarding.
9. Real-time subsystem
- Live classroom behavior is handled separately from normal REST flows through Socket.io.
- server/socket/liveRoom.js is the dedicated real-time module, likely managing room join/leave, presence, and live interaction for lecture sessions.
- The frontend has matching live-session pages such as student/LiveRoom.jsx and instructor/LiveLectures.jsx, which are the client endpoints for that socket-driven experience.
10. Notifications and async side effects
- notificationController plus utils/notify.js indicate server-side notification fanout to users.
- config/nodemailer.js suggests email is part of the side-effect pipeline, likely for auth recovery and important account/course events.
- config/cloudinary.js indicates external media storage for course assets or profile/media uploads.
11. AI-assisted learning flow
- The README calls out Google Gemini integration, and the frontend includes student/MCQGenerator.jsx, which is the visible AI feature surface.
- In architecture terms, AI is an auxiliary content-generation path, not the main request path: a user action triggers server-side generation, then the generated quiz/material is rendered back into the learning workflow.
12. Operational/runtime boundaries
- The server depends on MongoDB, JWT secrets, and Gemini API credentials; the README also mentions Redis/BullMQ for heavier background processing, though no queue module is visible in the tree.
- server/seeds/index.js suggests the backend can bootstrap initial data for development or demo environments.
- The repo’s directory names are client/ and server/ even though the README refers to frontend/ and backend/.
13. End-to-end data flow
- Typical flow: a React page calls a domain API module → axios sends request to Express route → middleware authenticates/authorizes → controller reads/writes Mongoose models → response updates store/UI.
- For live lectures, the flow splits: REST is used for setup/persistence, while Socket.io handles real-time classroom interaction.
- For AI/notifications/email, the controller triggers an external service or utility, then persists or broadcasts the result back into the app state.
Main entry points: App.jsx Routing · student Student pages · api API layer · controllers Controllers
Components 21
Client
React/Vite frontend for public, admin, instructor, and student experiences.
- App shell · Bootstraps the SPA and route composition.
client/src/main.jsx - Routing · Top-level app shell and route wiring.
client/src/App.jsx - API layer · Centralized client-to-server domain services.
client/src/api - Layouts · Public, authenticated, and student layout wrappers.
client/src/components/layout - UI kit · Reusable atoms and cards used across roles.
client/src/components/ui - Public pages · Home, browse, and course detail views.
client/src/pages/public - Auth pages · Register, login, and password reset flows.
client/src/pages/auth - Admin pages · Management views for users, courses, instructors, and lectures.
client/src/pages/admin - Instructor pages · Course creation and live lecture management.
client/src/pages/instructor - Student pages · Learning, progress, live room, and AI quiz experiences.
client/src/pages/student - State store · Auth, course, and UI state management.
client/src/store - Hooks · Auth-aware and debounce behavior shared by pages.
client/src/hooks
Server
Express/Mongo backend with REST, auth, real-time, and domain services.
- Server app · Starts the API server and connects runtime services.
server/index.js - Routes · Thin route modules for each business domain.
server/routes - Auth guard · Authentication and role-based access control.
server/middleware - Controllers · Business logic layer behind the route modules.
server/controllers - Data models · Persistent domain state for users, courses, lectures, progress, and notifications.
server/models - Live room · Real-time lecture presence and interaction handling.
server/socket/liveRoom.js - Shared utils · Token, response, error, and notification helpers.
server/utils - Config · Database, email, and media integrations.
server/config - Seed data · Initial development or demo data loading.
server/seeds/index.js
Connections 26
- App shell → Routing: mounts · The app entry renders the routed shell.
- Routing → Layouts: wraps · Routes are organized by layout shells.
- Routing → Public pages: serves · Public routes render marketing and browse pages.
- Routing → Auth pages: serves · Auth routes render login and recovery flows.
- Routing → Admin pages: serves · Admin routes render management dashboards.
- Routing → Instructor pages: serves · Instructor routes render teaching workflows.
- Routing → Student pages: serves · Student routes render learning workflows.
- Public pages → API layer: reads data · Public pages fetch course and catalog data.
- Auth pages → API layer: auth calls · Auth screens call login and recovery endpoints.
- Admin pages → API layer: admin calls · Admin dashboards use domain API modules.
- Instructor pages → API layer: teaching calls · Instructor pages call course and live lecture services.
- Student pages → API layer: learning calls · Student pages call progress, course, and notification services.
- Student pages → State store: state · Learning UI consumes shared client state.
- Admin pages → UI kit: uses · Admin views reuse shared UI primitives.
- Student pages → UI kit: uses · Student views reuse shared UI primitives.
- Hooks → Student pages: supports · Hooks provide cross-page auth and search behavior.
- Server app → Routes: mounts · Express mounts the domain route modules.
- Routes → Auth guard: protects · Routes rely on auth and role middleware.
- Routes → Controllers: delegates · Routes forward requests to controllers.
- Controllers → Data models: persists via · Controllers read and write Mongo models.
- Controllers → Shared utils: uses · Controllers use shared response, token, and notify helpers.
- Server app → Live room: starts · Server initializes the live Socket.io room layer.
- Controllers → Config: integrates · Controllers depend on DB, mail, and storage config.
- Server app → Seed data: bootstraps · Seed script supports initial data loading.
- API layer → Routes: HTTP · Client service modules call the Express API.
- Student pages → Live room: socket · Live room pages connect to real-time classroom flows.