How shawongazi7/leading-university-student-management-system works
1. Overall shape
- This is a server-rendered Node.js university portal, built around Express + EJS + MySQL.
- The application is organized as a classic layered monolith: app.js wires middleware and routes, routes/ handles HTTP boundaries, models/ encapsulates database access, and views/ renders role-specific pages.
2. Entry point and composition root
- app.js is the central bootstrap file. It likely initializes Express, configures sessions/security/logging, mounts route modules, serves static assets from public/, and connects to the database on startup.
- config.js and config/database.js provide shared configuration, while init-db.js and the scripts suggest startup-time table creation and demo data seeding.
3. Primary runtime and delivery model
- The system is not a SPA or API-first app; it delivers HTML directly from EJS templates.
- Browser requests flow into Express routes, which query/update MySQL through models and then return server-rendered pages.
- Frontend behavior is limited to small enhancements in public/js/app.js and styling in public/css/style.css.
4. Authentication and access control boundary
- Authentication is session-based via express-session, with middleware/auth.js enforcing protected routes and role checks.
- The auth subsystem supports login, registration, logout, profile access, password reset, and email verification.
- JWT is used only for stateless email links; normal user state is maintained in the server session.
5. Role-based application split
- There are two main authenticated experiences: views/student/* for students and views/admin/* for administrators.
- Route modules mirror this split: routes/student.js and routes/admin.js are the main role-specific boundaries.
- Students can view dashboards, results, tuition, clubs, events, and transcripts; admins manage data and reports from a dashboard-centric interface.
6. Domain modules and data ownership
- models/User.js owns accounts, identity, and profile-related data.
- models/Result.js handles academic results and transcript-related summaries.
- models/Club.js manages clubs and membership data.
- models/Event.js covers event publishing, registration, attendance, and feedback.
- models/Payment.js stores manual payment metadata for paid event registrations.
- models/TuitionFee.js represents tuition tracking.
- models/Settings.js appears to hold app-level configuration persisted in the database.
- models/Settings.js plus config/ indicate that some operational behavior is configurable through data as well as environment variables.
7. Public, student, and admin page topology
- views/public/* exposes read-only club and event browsing to anonymous users.
- views/auth/* contains login/register/reset/profile flows.
- views/student/* contains student dashboard, transcript, results, tuition, and participation pages.
- views/admin/* contains CRUD and reporting screens for students, clubs, events, results, tuition, settings, and uploads.
- Shared layout and navigation live in views/layout.ejs and views/partials/*, indicating a template-driven shell with role-specific sidebars.
8. Data flow for academic and club/event workflows
- Admins create or import core records through admin forms and bulk workflows.
- Those actions persist into MySQL through model methods, then surface in public/student views via separate read routes.
- Student-facing pages are largely derived views over the same underlying records, especially for results, club membership, and event participation.
9. Payment and registration flow
- Event payments are deliberately manual, not integrated with a gateway.
- For paid events, a student registration can begin in a pending state, then a Payment record stores transaction ID, payment method, status, and payment date.
- This is a distinct subsystem from tuition tracking: event payments are transactional metadata, while tuition has its own admin-managed record model and student summary page.
10. Database and environment boundary
- The README states the active database path is MySQL via config/database.js, even though config/database-sqlite.js exists as an alternate configuration artifact.
- .env.example shows the app depends on environment variables for server port, session secret, DB credentials, JWT secret, and optional email credentials.
- On startup, the system appears to auto-create tables and seed demo accounts/data, which makes local setup self-contained.
11. File handling and assets
- multer-style upload handling is implied by the presence of public/uploads/, uploads/, and admin upload screens such as result import/upload pages.
- The repository also contains CSV-oriented admin workflows and scripts, so bulk import/export is a notable data ingestion path.
- Static assets are isolated under public/, keeping uploaded media and frontend assets separate from server code.
12. Operational scripts and validation utilities
- The scripts/ folder contains non-user-facing tooling for seeding, inspecting the database, smoke-checking routes, fixing branding, and testing functionality.
- These scripts act as maintenance and verification entry points around the main app, suggesting the repo is intended for demo/local administration as much as day-to-day use.
- Together, they reinforce that the core architecture is a single deployable web app with supporting lifecycle utilities rather than a distributed service system.
Main entry points: admin.js Admin routes · app.js app.js · student.js Student routes · public.js Public routes
Components 23
Core runtime
Bootstrap, configuration, middleware, and HTTP routing for the monolith.
- app.js · Composition root that wires middleware, sessions, static assets, routes, and startup behavior.
app.js - Config · Shared application configuration used by the server and subsystems.
config.js - DB config · Primary database connection settings for the active MySQL runtime.
config/database.js - Auth guard · Session and role-based access control for protected routes.
middleware/auth.js - Auth routes · Login, registration, logout, profile, and password reset boundaries.
routes/auth.js - Public routes · Anonymous browsing for clubs and events.
routes/public.js - Student routes · Authenticated student pages for academic and participation workflows.
routes/student.js - Admin routes · Administrative CRUD, reporting, import, and settings pages.
routes/admin.js - Club routes · Club-specific boundaries shared across public, student, and admin flows.
routes/club.js
Domain models
MySQL-backed data access and business entities.
- Users · Accounts, identity, profiles, and access-related data.
models/User.js - Results · Academic results and transcript summaries.
models/Result.js - Clubs · Clubs and membership relationships.
models/Club.js - Events · Event publishing, registration, attendance, and feedback.
models/Event.js - Payments · Metadata for paid event registrations and payment tracking.
models/Payment.js - Tuition · Tuition fee tracking and student summaries.
models/TuitionFee.js - Settings · Persisted application settings that complement environment configuration.
models/Settings.js
Server views
EJS templates for public, auth, student, and admin experiences.
- Layout shell · Shared template shell and navigation structure for the app.
views/layout.ejs - Auth pages · Login, registration, reset, and profile screens.
views/auth/login.ejs - Student pages · Dashboard, results, transcript, tuition, clubs, and events pages for students.
views/student/dashboard.ejs - Admin pages · Administrative dashboards, CRUD forms, imports, reports, and settings.
views/admin/dashboard.ejs - Public pages · Anonymous club and event browsing pages.
views/public/clubs.ejs
Connections 33
- app.js → Config: loads · Bootstraps shared runtime settings.
- app.js → DB config: connects · Uses the active MySQL database configuration.
- app.js → Auth guard: applies · Installs session and role checks before protected handlers.
- app.js → Auth routes: mounts · Registers authentication boundaries.
- app.js → Public routes: mounts · Registers anonymous read-only pages.
- app.js → Student routes: mounts · Registers the student experience.
- app.js → Admin routes: mounts · Registers the admin experience.
- app.js → Club routes: mounts · Registers club-related route handling.
- app.js → Init DB: initializes · Runs startup database setup behavior.
- Init DB → Seed demo: seeds · Populates demo data and accounts when needed.
- Auth routes → Users: reads/writes · Creates and authenticates account records.
- Student routes → Users: reads · Loads student identity and profile data.
- Student routes → Results: reads · Builds results and transcript views.
- Student routes → Clubs: reads · Shows memberships and club participation.
- Student routes → Events: reads/writes · Displays events and handles registrations.
- Student routes → Tuition: reads · Displays tuition summaries.
- Admin routes → Users: reads/writes · Manages students and account data.
- Admin routes → Clubs: reads/writes · Manages clubs and memberships.
- Admin routes → Events: reads/writes · Manages events and attendance.
- Admin routes → Results: reads/writes · Imports and reports academic results.
- Admin routes → Payments: reads/writes · Tracks manual event payment metadata.
- Admin routes → Tuition: reads/writes · Manages tuition records.
- Admin routes → Settings: reads/writes · Persists app settings from the admin area.
- Public routes → Clubs: reads · Lists clubs and club details.
- Public routes → Events: reads · Lists public events and event details.
- Club routes → Clubs: reads/writes · Shared club domain boundary.
- Auth routes → Auth pages: renders · Serves auth-related templates.
- Public routes → Public pages: renders · Serves public browsing pages.
- Student routes → Student pages: renders · Serves student-facing pages.
- Admin routes → Admin pages: renders · Serves admin pages and reports.
- Student routes → Layout shell: uses · Composes pages within the shared template shell.
- Admin routes → Layout shell: uses · Composes admin pages within the shared shell.
- Public routes → Layout shell: uses · Composes public pages within the shared shell.