sifatul-islam-onik/cse-3200-system-development-project-ml-integrated-lms

1. Overall shape

- This repo is an OBE-focused LMS split into four deployable pieces: client/ React SPA, server/ Node/Express API, ml_server/ FastAPI OCR service, and ml_server_huggingface/ a deployment variant of the OCR service.

- The main boundary is between the browser UI, the core API, and the asynchronous OCR subsystem.

2. Frontend boundary: client/

- The React app serves three roles: admin, teacher, and student.

- It contains public auth pages, protected profile access, and role-based dashboards.

- Most UI features are domain-driven screens for courses, marks, attainment, course profiles, and OCR job status. It talks to the backend through service modules in client/src/services.

3. Backend entrypoint and shared middleware: server/server.js

- The Express server is the central application coordinator.

- It initializes security and request handling concerns such as CORS, payload limits, auth/role middleware, MongoDB connection, route registration, and startup of the OCR worker/queue infrastructure.

- This server is both the main API and the orchestrator for background processing.

4. Identity and access management

- Authentication is JWT-based with login, registration, OTP/email verification, forgot/reset password, and profile endpoints under authRoutes.

- Authorization is role-based, with separate controls for admin, teacher, and student via middleware.

- User approval/state management is part of the admin workflow, not just authentication.

5. Core academic domain

- Courses, course outcomes, program outcomes, course proposals, and course profiles are separate but connected backend modules.

- The curriculum side of the system centers on validating OBE structure, assigning teachers/batches, defining CO/PO metadata, and maintaining course profile data.

- This is the “master data” layer that other workflows depend on.

6. Assessment and attainment workflows

- The attainment subsystem covers CTs, assignments, lab activities, section-based workflows, term exam marks, and result computation.

- The backend has dedicated models for each attainment type and routes for capturing, calculating, and viewing attainment outputs.

- Results are a downstream product of the assessment data and can be published or unpublished.

7. Asynchronous OCR pipeline

- OCR is not handled synchronously in the request thread; it is a queued background workflow.

- ocrRoutes accept jobs, Redis + Bull hold the queue, and server/workers/ocrWorker.js performs processing.

- The worker submits images to an ML service, then stores job state, extracted marks, and confidence for later polling by the client.

8. ML service boundary

- ml_server/ and ml_server_huggingface/ are separate FastAPI microservices exposing health and extraction endpoints.

- They are protected by an API key and are treated as replaceable inference backends.

- The OCR stack uses layout/table detection, cell detection, and text recognition to extract marks from uploaded sheet images.

9. Persistence model

- MongoDB is the system of record, accessed through Mongoose models in server/models.

- The schema set is organized around users, curriculum entities, attainment records, term marks, term results, and OCR-related job metadata.

- Redis is not a primary store; it is the job-queue and coordination layer for OCR.

10. Supporting services and imports/exports

- The system uses email for verification and password reset flows.

- Excel/CSV import-export is part of admin onboarding and bulk data operations, especially teacher/student credential workflows.

- There are utility modules for curriculum validation, course profile initialization, password reset, seeds, and worker registry/health management, which support the main subsystems rather than forming separate domains.

11. How data flows end to end

- Typical academic flow: user logs in → role-gated dashboard → edits curriculum/marks/attainment → backend persists to MongoDB → results are computed and viewed.

- OCR flow: teacher/admin uploads an image → API enqueues a job → worker calls the ML service → extracted marks return to the API layer → client polls status and consumes the result.

12. Operational separation

- The repo is designed to run with MongoDB, Redis, the API server, the React client, and one of the FastAPI OCR services as distinct processes/containers.

- That separation is important for the architecture diagram: UI, transactional API, queue/worker, and ML inference are separate trust and scaling boundaries.