zaggi-225/kendra-project

Purpose and entry points

This repository is a student academic-management system with a static browser UI, a Python API backend, and Supabase/PostgreSQL persistence. The frontend begins at index.html; feature pages are under pages/. The API application entry point is backend/app/main.py. Database lifecycle is defined through ordered Supabase migrations in supabase/migrations/.

Frontend feature modules

The browser client is plain HTML/CSS/JavaScript rather than a bundled framework application. js/app.js is the shared client bootstrap, while feature-specific scripts drive student, attendance, DLT, and exam workflows:

• pages/student-master.html, js/studentMaster.js

• pages/attendance.html, js/attendance.js

• pages/dlt.html, js/dlt.js

• pages/exam.html, js/exam.js

Shared presentation structure is centralized in css/base.css, css/layout.css, and css/components.css. js/mockData.js indicates the UI can operate against local/mock data during development or before API integration.

API composition and request boundary

The backend is structured as a FastAPI-style layered service. backend/app/main.py assembles the application and routes; domain HTTP endpoints are separated into routers:

• backend/app/routers/students.py

• backend/app/routers/attendance.py

• backend/app/routers/assessments.py

• backend/app/routers/dlt.py

• backend/app/routers/enrollments.py

Routers form the external API boundary and should handle HTTP concerns, validation invocation, and dependency wiring rather than persistence logic.

Domain service layer

Business operations are organized per educational domain behind service modules:

• backend/app/services/student_service.py

• backend/app/services/enrollment_service.py

• backend/app/services/attendance_service.py

• backend/app/services/assessment_service.py

• backend/app/services/dlt_service.py

The primary control flow is frontend feature action → API router → domain service → database dependency/connection → Supabase PostgreSQL. Services are the key place to coordinate cross-entity rules, such as enrollment context for attendance and assessment records.

Data contracts and persistence access

Backend models and schemas distinguish stored/domain data from API request/response contracts. Relevant parallel structures include:

• backend/app/models/student.py, backend/app/schemas/students.py

• backend/app/models/attendance.py, backend/app/schemas/attendance.py

• backend/app/models/assessment.py, backend/app/schemas/assessment.py

• backend/app/models/dlt.py, backend/app/schemas/dlt.py

Database connectivity and injected request-scoped access are isolated in backend/app/db/connection.py and backend/app/db/dependencies.py. Configuration and security boundaries are in backend/app/core/config.py and backend/app/core/security.py.

Supabase relational model and governance

Supabase provides PostgreSQL infrastructure, schema evolution, seeds, and row-level security. The data model progresses from identity/reference entities to school operations:

• Profiles and academic/class structure: 001_create_profiles.sql, 002_create_academic_years.sql, 003_create_classes.sql

• Student and enrollment relationships: 004_create_students.sql, 008_create_student_enrollments.sql

• Operational records: 010_create_attendance.sql, 011_create_dlt.sql, 012_create_assessments.sql

Indexes and RLS are explicit architectural stages in supabase/migrations/013_create_indexes.sql and supabase/migrations/014_create_rls.sql. Therefore, API authorization must remain compatible with Supabase’s database-level access policies rather than treating the database as an unrestricted internal store.