abhi-dr/angaarxw3grads-portal

1. What this repository is

- A single Django monolith for an education/training platform. It serves multiple user roles—public visitor, student, instructor, and administrator—from the same codebase and database.

2. Core application shell

- The angaar_hai package is the platform layer: settings.py, urls.py, wsgi.py, asgi.py, plus middleware.py, custom_decorators.py, mail_utility.py, tasks.py, and celery.py.

- This is where request routing, auth/session setup, async task wiring, and process entrypoints are centralized.

3. Identity and authentication boundary

- accounts owns the custom user/auth stack: custom user model migration rewiring, login/registration views, OAuth integration, auth backend/adapters, middleware, signals, and validation/management commands.

- It is the system boundary for sign-in, account lifecycle, and Google OAuth configuration.

4. Public/home-facing layer

- home contains the public site, landing pages, campaign/event pages, and registration flows such as Flames/Flare.

- It also holds campaign-specific models, resources, and view logic, so this app acts as the public entry point before a user becomes a student or participant.

5. Student portal

- student is the largest role app and acts as the learner-facing workspace.

- It covers dashboards, profiles, certificates, payments, batch/course participation, hackathons, JOVAC learning pages, MCQ interaction, doubt solving, notifications, and related APIs.

- It includes its own serializers, permissions, and API routes, so a lot of the student UI is server-rendered but backed by JSON endpoints for dynamic pages.

6. Instructor portal

- instructor mirrors a subset of the student/administrator capability set, focused on managing batches, sheets, events, and JOVAC content from the instructor side.

- It also exposes APIs with serializers and permission checks, implying a separate role boundary rather than one shared admin UI.

7. Administrator console

- administration is the operational back office for staff. It includes batch management, alumni, articles, events, JOVAC management, MCQ/problem tooling, sheet APIs, WhatsApp-related views, and email/helper functions.

- The presence of consumers.py and routing.py suggests real-time/channel-based features in addition to standard HTTP views.

8. Practice/execution subsystem

- practice is the coding-practice engine: problem sheets, MCQ questions, submissions, test cases, execution-related views, and async utilities.

- This is the part of the system that likely interacts with background execution or sandboxing workflows rather than simple CRUD screens.

9. JOVAC content flow

- JOVAC content is a cross-cutting subsystem spanning student, instructor, administration, and practice.

- The README shows it uses ordered CourseSheet items and mixed item types such as tutorials, assignments, MCQs, and coding tasks.

- Navigation, submission, and page rendering all depend on preserving sheet context through query parameters and API responses, so the learning path is treated as a deterministic sequence rather than independent pages.

10. API structure

- Each major role has its own API namespace under student/api, instructor/api, and administration/api.

- These APIs are organized with serializers, permission classes, and view modules, which cleanly separate JSON/data concerns from the HTML template layer.

- There is also an older student/api.py, which looks like legacy API surface kept alongside the newer package layout.

11. Data model and schema evolution

- The repository relies heavily on migrations across apps, including custom-user rewiring and later cleanup migrations.

- That indicates the database schema has evolved over time around a shared core identity model, plus app-specific entities for courses, sheets, registrations, certificates, batches, and campaign objects.

12. Async, realtime, and integration points

- Celery is present for background jobs, and ASGI is configured, so the runtime supports async processing beyond standard request/response.

- Integrations visible in the tree include email delivery, Google OAuth, WhatsApp-related flows, payment utilities, image uploads, and certificate generation.

- These are not isolated services in this repo, but external dependencies that materially affect the system’s architecture.

13. Presentation layer

- The app is predominantly server-rendered with Django templates under templates/, organized by role and feature.

- demo_static/ contains the bundled frontend assets: Bootstrap, jQuery, ApexCharts, TinyMCE, media files, and feature-specific CSS/JS.

- This points to a traditional Django template architecture with some richer client-side behavior on top, not a separate SPA frontend.

14. How requests typically flow

- A request enters Django through the root URL config, is routed to the relevant app, authenticated/authorized by the role-specific logic, and then either rendered as HTML or served as JSON.

- Content-heavy paths such as JOVAC, sheets, MCQs, and submissions often combine server-rendered pages with API calls and background work, while admin/instructor/student views remain tightly coupled to the shared database.