humayranuha/group_sync

1. High-level shape

GroupSync is organized as a three-part system: a Laravel backend for core domain logic and persistence, a JavaScript frontend for role-based user interaction, and a small Node/Express auxiliary service under backend/. The main runtime boundary is between the browser UI and the Laravel API; the Node service appears to support a specialized side function rather than host the main app.

2. Frontend application boundary

The UI is a modular single-page style frontend with separate experiences for students, professors, admins, and public users. It has dedicated layouts (AuthLayout, MainLayout, ProfessorLayout, StudentLayout) and page groups for each role, which makes role-based navigation a first-class architectural concern.

3. Frontend component structure

The frontend is split into reusable layers: components/ for analytics, charts, common widgets, forms, and layout chrome; services/ for API-facing logic; store/ for client state; and utils/ for helpers, formatting, validation, and PDF generation. This suggests the UI is not just static pages but a data-driven client that orchestrates multiple backend calls.

4. Backend application boundary

The Laravel app under code/app is the system of record. It exposes HTTP endpoints through routes/api.php and routes/web.php, with controllers such as ApiController, DashboardController, and NodeEmailController. The backend owns authentication, domain rules, score calculation, reporting data, and administrative operations.

5. Core domain model

The persistent model centers on User, Course, Group, Assignment, PeerReview, ContributionScore, Attendance, WorkingHour, Notification, and AuditLog. The migrations show many-to-many links for course_student and group_members, which means the system models both course enrollment and group membership explicitly rather than embedding them in single tables.

6. Contribution scoring pipeline

A key backend workflow is the weighted contribution score. The scheduled Artisan command CalculateContributionScores.php indicates periodic aggregation of multiple signals: GitHub activity, attendance, logged working hours, and peer reviews. The resulting ContributionScore record is then consumed by dashboards, alerts, and professor reports.

7. Collaboration and course management flow

Professors create courses and assignments, enroll students, and inspect all groups within a course. Students create or join groups using invitation codes, then connect a GitHub repository for activity tracking. This flow is supported by the group/course models and by frontend pages for course management, group details, and repository connection.

8. Analytics and reporting

The product has a dedicated analytics layer for visualizing contribution patterns, low performers, activity consistency, commit trends, and team comparisons. On the frontend these are represented by analytics/chart components and professor/student analytics pages; on the backend the data is prepared from the scoring and domain tables. Report generation is a separate concern, with a professor PDF report page and a shared pdfGenerator utility on the client side.

9. Authentication and role control

Authentication is role-based and appears to use Laravel’s token/session stack with Sanctum configured in config/sanctum.php. The frontend has protected routes and role-specific layouts, while the backend has user/account management plus admin controls. This makes authorization a major boundary: public pages are separate from authenticated student, professor, and admin areas.

10. Notifications, auditability, and operational data

The presence of Notification and AuditLog models, plus migrations for logs and sessions, shows that the system tracks user-visible alerts and admin-facing history. This supports feedback on score changes, pending peer reviews, and system activity monitoring, which are part of the admin and professor experiences.

11. External integrations

GitHub is the main external data source, used to capture repository activity for contribution analytics. Email is also a supporting integration, reflected by NodeEmailController and mail config. There is also an aiService on the frontend, which suggests AI-assisted feedback is a separate integration surface rather than core domain logic.

12. Deployment/runtime layout

The repository contains both code/public/frontend and a parallel top-level frontend/ tree with the same structure, implying the frontend is maintained as a standalone artifact that is also published into Laravel’s public web root. Runtime-wise, the backend is PHP/Laravel with MySQL, while the frontend is a static JS application built with modern tooling such as Vite/Tailwind, and the auxiliary Node server runs separately when needed.

13. What an architecture diagram should emphasize

The most important boxes are: Browser UI, Laravel API/domain layer, MySQL database, GitHub API, and the score/reporting pipeline. The critical arrows are: user actions from the role-based frontend to Laravel endpoints, Laravel writes/reads from MySQL, Laravel periodically recalculates contribution scores, and GitHub activity feeds into that scoring process. The Node service should be shown as a secondary integration component, not the primary backend.