How masudranamushfiq/student-management-p1 works
1. This is a Laravel 13 application for student management, built around classic server-rendered web flows plus a token-authenticated API. The architecture is centered on HTTP controllers, Eloquent models, database migrations/seeders, and Blade views.
2. The domain is split across a small set of core models: Student, Department, Hall, User, and AuditLog. Students are the primary entity, with departments and halls acting as supporting references, while audit logs capture important system actions.
3. Web traffic enters through routes/web.php and routes/api.php, then reaches controllers under app/Http/Controllers. The main controller set covers admin, authentication, student management, department-specific views, and role/user administration.
4. Request validation is explicitly separated into Form Request classes like StoreStudentRequest and UpdateStudentRequest, which means controllers handle orchestration while validation logic stays outside them. Authorization is enforced through policies for student, department, and hall access, backed by Spatie Laravel Permission.
5. The admin boundary is distinct: Admin/DashboardController and Admin/UserManagementController support dashboards, user/role management, and log review. This is the highest-privilege surface and is where role assignment and audit visibility are concentrated.
6. Department and exam workflows are separate from admin CRUD. The repository includes dedicated Blade views for department home, department student listing, and exam search/edit screens, indicating role-specific UIs rather than one shared generic interface.
7. Auditability is built into the domain. StudentObserver likely records lifecycle changes into AuditLog, and there are admin views for listing and inspecting those logs, so change tracking is a first-class data flow rather than an afterthought.
8. Authentication is split by channel: web login/registration lives alongside API authentication. The README and config show Laravel Sanctum for bearer-token API access, while the web side uses Blade-driven auth pages.
9. There is a modular subsystem under Modules/Student, isolated with its own service providers, routes, config, database assets, views, and tests. This module uses nwidart/laravel-modules, so it behaves like a self-contained feature boundary with its own controller and asset pipeline.
10. Frontend assets are compiled with Vite, with both root-level assets and module-level JS/Sass entries. That means the UI is built from Blade templates, but asset ownership is split between the main app and the Student module.
11. Persistence is managed through migrations and seeders. The schema includes users, students, departments, halls, personal access tokens, Spatie permission tables, and audit logs; seeders bootstrap roles, permissions, an admin user, and sample reference data.
12. Operationally, the repo is a conventional Laravel application with standard storage, cache, queue, and public entrypoint structure. The important architecture boundaries for a diagram are: web vs API, admin vs department/exam roles, core app vs Student module, and request handling vs validation/authorization vs persistence/auditing.
Main entry points: web.php Web routes · dashboard.blade.php Blade views · Student.php Domain models · StudentController.php Student CRUD
Components 20
Main App
Primary Laravel web/API application for student management.
- Web routes · Server-rendered entry routes for the main app.
routes/web.php - API routes · Token-authenticated API entry routes.
routes/api.php - Auth flow · Web login and registration handling.
app/Http/Controllers/WebAuthController.php - Student CRUD · Core student management orchestration.
app/Http/Controllers/StudentController.php - Department UI · Department-specific views and actions.
app/Http/Controllers/DepartmentController.php - Hall UI · Hall management orchestration.
app/Http/Controllers/HallController.php - API auth · Bearer-token API authentication endpoints.
app/Http/Controllers/AuthController.php - Admin dashboard · High-privilege admin landing and overview.
app/Http/Controllers/Admin/DashboardController.php - User admin · User, role, and log management surface.
app/Http/Controllers/Admin/UserManagementController.php - Form requests · Separated request validation for student, department, and hall writes.
app/Http/Requests/StoreStudentRequest.php - Policies · Access control for student, department, and hall resources.
app/Policies/StudentPolicy.php - Blade views · Server-rendered UI for auth, admin, department, exam, and student flows.
resources/views/admin/dashboard.blade.php
Student Module
Isolated nwidart module with its own routes, provider, views, and assets.
- Module provider · Student module service provider and route registration.
Modules/Student/app/Providers/StudentServiceProvider.php - Module routes · Module-local web and API routes.
Modules/Student/routes/web.php - Module controller · Student module controller boundary.
Modules/Student/app/Http/Controllers/StudentController.php - Module UI · Module-specific Blade views plus Vite-driven JS/Sass assets.
Modules/Student/resources/views/index.blade.php
Data & Ops
Persistence, authorization, auditing, and bootstrap data.
- Domain models · Core entities for students, departments, halls, users, and audit logs.
app/Models/Student.php - Student observer · Lifecycle hook that records student changes into audit logs.
app/Observers/StudentObserver.php - Schema & seed · Database schema and bootstrap data for roles, users, and reference records.
database/migrations/2026_05_05_020837_create_students_table.php - Auth config · Sanctum bearer tokens and Spatie permission wiring.
config/sanctum.php
Connections 32
- Web routes → Auth flow: auth pages · Web routes direct login and registration flows.
- Web routes → Student CRUD: students · Routes dispatch to student management actions.
- Web routes → Department UI: departments · Routes dispatch to department-specific screens.
- Web routes → Hall UI: halls · Routes dispatch to hall management screens.
- Web routes → Admin dashboard: admin · Admin area routes enter through the dashboard controller.
- Web routes → User admin: users & logs · Admin routes reach user, role, and audit views.
- API routes → API auth: api auth · API routes expose token-based authentication endpoints.
- Student CRUD → Form requests: validates · Student writes rely on dedicated form request classes.
- Department UI → Form requests: validates · Department writes are validated outside controllers.
- Hall UI → Form requests: validates · Hall writes are validated outside controllers.
- Student CRUD → Policies: authorizes · Student access is gated by policy checks.
- Department UI → Policies: authorizes · Department access is gated by policy checks.
- Hall UI → Policies: authorizes · Hall access is gated by policy checks.
- Student CRUD → Domain models: reads/writes · Student workflows operate on Eloquent domain models.
- Department UI → Domain models: reads/writes · Department views and updates use the shared models.
- Hall UI → Domain models: reads/writes · Hall workflows persist through the domain models.
- Student observer → Domain models: observes · Observer attaches to student lifecycle events.
- Student observer → Domain models: logs · Lifecycle changes are captured as audit records.
- Admin dashboard → Blade views: renders · Admin dashboard is presented through Blade views.
- User admin → Blade views: renders · User and log management screens are Blade-based.
- Student CRUD → Blade views: renders · Student CRUD flows render server-side pages and PDFs.
- Department UI → Blade views: renders · Department home and student listing are Blade views.
- Hall UI → Blade views: renders · Hall pages render from Blade templates.
- Auth flow → Blade views: renders · Web authentication pages are Blade-driven.
- API auth → Auth config: uses · API auth depends on Sanctum and permission config.
- User admin → Auth config: roles · Admin user management concentrates role assignment.
- Schema & seed → Domain models: creates schema · Database tables back the core domain models.
- Schema & seed → Auth config: boots auth · Migrations and seeders initialize tokens and permissions.
- Module provider → Module routes: registers · Module service provider wires module route files.
- Module routes → Module controller: dispatches · Module routes reach the module controller.
- Module controller → Module UI: renders · Module controller serves module-local UI.
- Module provider → Module UI: bootstraps · Module provider connects module resources and assets.