okayabedin/diu-cgpa

1. Project type and runtime

- This is a single-page, browser-based academic calculator for DIU students.

- The core app runs as static HTML/CSS/Vanilla JavaScript in the browser.

- There is no persistent database or authenticated backend in the repo; results are processed locally after retrieval.

2. Primary entry point

- index.html is the main application shell.

- It likely wires in the stylesheet(s), UI containers, and the JavaScript modules under js/.

- assets/ holds static visuals and styling; robots.txt, sitemap.xml, and _headers indicate deployment-oriented static-site setup.

3. Client-side application boundary

- The browser app is the main architecture boundary: user input enters through the UI, data is fetched from the university-facing API, then transformed and rendered entirely on the client.

- The README emphasizes privacy by keeping academic data local after retrieval, so the main flow is fetch → calculate → render/export.

4. Data acquisition layer

- js/api.js is the front-end API integration layer.

- It is paired with netlify/functions/api-proxy.js, which exists to proxy university API requests and handle CORS issues.

- This introduces a small serverless boundary: the browser talks to a Netlify Function, which forwards requests to the external DIU academic system.

5. Calculation and domain logic

- js/calculator.js contains the CGPA/GPA computation logic.

- The README indicates weighted GPA calculation, retake handling, and special treatment of grades like F and I.

- This is the main domain engine of the app: it converts raw academic records into semester GPA, cumulative CGPA, and derived summaries.

6. Manual planning workflow

- js/manual-input.js supports the “manual CGPA calculator” path described in the README.

- This path is separate from fetched academic records: users can add hypothetical courses and grades to simulate future semesters.

- assets/styles/manual-calculator.css suggests this workflow has its own UI treatment and layout.

7. Presentation components

- js/components/StudentInfo.js, SemesterList.js, and ResultCard.js are the primary UI building blocks.

- Their names imply a presentation-layer split into:

- student summary/header,

- semester-by-semester transcript list,

- result/CGPA display cards.

- This keeps rendering concerns separate from API and calculation logic.

8. Navigation and app orchestration

- js/navigation.js likely manages switching between major views such as fetch mode, manual calculator, and result views.

- js/ui.js is the broader UI controller that coordinates rendering, state updates, and user interactions.

- Together they act as the orchestration layer between input, data, calculation, and output.

9. Utilities and shared helpers

- js/utils/helpers.js contains shared helper functions.

- js/utils/Iterator.js suggests a custom iteration abstraction, likely used for traversing semester/course collections in a consistent way.

- These modules are supporting infrastructure rather than primary app flows.

10. Static assets and visual system

- assets/styles/main.css holds the core styling for the app shell and responsive layout.

- assets/img/ contains logos and icons used in branding and UI.

- The README mentions Bootstrap, FontAwesome, Chart.js, and HTML2PDF.js, so the UI likely depends on those libraries for responsive layout, icons, charts, and PDF generation, even though they are not shown in the file tree.

11. Output and reporting

- The app supports transcript-style output, CSV export, and visual GPA tracking.

- These capabilities likely originate from the calculated result model and are rendered or exported from the UI layer rather than from a backend service.

- Chart rendering is a client-side concern tied to the result presentation flow.

12. Deployment architecture

- netlify.toml plus the netlify/functions/ directory indicate deployment on Netlify.

- The serverless function is used primarily as an integration shim, not as an application server.

- This means the deployment model is: static frontend assets served from Netlify, with a lightweight function layer for API proxying.

13. Testing/debug artifacts

- test-semester-names.js, test-sorting.js, and debug-sort.js suggest the repo includes small targeted scripts for validating transcript parsing/sorting behavior.

- These are likely developer-side tools around the data transformation layer, not part of production runtime.

14. Overall data flow

- The typical architecture flow is:

- user enters a student ID or manual course data,

- the client calls the API layer,

- the Netlify proxy forwards external requests when needed,

- raw academic records are normalized and processed by calculator logic,

- the UI components render semester history, CGPA summary, charts, and exportable outputs.

- The main architectural separation is between static client UI, domain calculation logic, and a minimal proxy function for external API access.