Didactpal

Problem

Teachers spend significant time converting static syllabi and course materials into assessments and live classroom activities. Didactpal connects syllabus upload, AI-assisted quiz generation, teacher review, live quiz hosting, student participation, and result computation into one authenticated workflow.

Users

Teachers/instructors and student participants.

My Role

Prajesh designed and built the Django REST Framework API for classroom, syllabus, activity, and live-session workflows. He implemented authentication, syllabus/PDF processing, AI quiz generation through OpenRouter, live WebSocket sessions with Django Channels, and the Flutter client for teacher and student workflows. He also contributed to testing, CI/CD, and VPS deployment.

Architecture

The client is a Flutter app covering both teacher and student workflows. The backend is a Django REST Framework API backed by PostgreSQL, with JWT authentication (access/refresh tokens, django-allauth / dj-rest-auth / SimpleJWT) and mandatory email verification. Uploaded syllabi are parsed with pypdf to extract text, which is then passed to OpenRouter for AI-assisted syllabus structuring and quiz question generation. Live classroom sessions run over WebSockets via Django Channels and Daphne, using Redis strictly as the Channels layer rather than for caching. The Flutter client stores tokens in secure local storage. GitHub Actions runs backend/frontend CI and deploys to a self-managed VPS behind nginx and systemd, running migrations and collectstatic as part of the deployment flow.

Key Features

• Teacher account creation with mandatory email verification
• Authenticated classroom/course workflows
• PDF syllabus upload and text extraction
• AI-assisted syllabus structure parsing
• AI-generated quiz questions
• Teacher review of generated quiz content
• Live quiz hosting
• Student joining and answering from devices
• WebSocket-based live classroom state
• Live result computation and broadcast
• Account/data lifecycle handling with cascading deletion
• Secure mobile token storage

Technical Decisions

• Used REST APIs for standard classroom, syllabus, activity, and account workflows
• Used WebSockets only for live classroom state instead of making the entire app real-time
• Used Django Channels, Daphne, and Redis Channels layer for live quiz sessions
• Kept AI inside a backend service-layer workflow rather than exposing raw LLM behavior directly to the client
• Used pypdf to extract uploaded syllabus text before passing structured content into AI workflows
• Used JWT rotation/blacklisting and mandatory email verification for safer authentication
• Added targeted database indexes and relationship rules for query performance and safe account deletion
• Used Flutter secure storage for JWT handling on the client

Tradeoffs

• REST plus WebSockets was chosen instead of a fully real-time architecture to keep the system simpler and fit-for-purpose
• Redis is used as a Channels layer, not as general application caching
• AI generation is useful for teacher productivity, but teacher review remains important before classroom use
• Uploaded syllabus files use local/filesystem storage in the evidenced version rather than cloud object storage
• Production deployment is VPS-based rather than containerized production deployment

Security, Reliability & Testing

• Mandatory email verification before login
• JWT access/refresh tokens with rotation and blacklist behavior
• Secure local token storage through flutter_secure_storage
• JWT-authenticated WebSocket connections
• DRF endpoint throttling and dedicated rate-limit tests
• SECRET_KEY / DEBUG production guards
• CORS allowlist
• CASCADE/PROTECT relationships for account and data lifecycle safety
• Backend pytest coverage for authentication, throttling, realtime broadcast, syllabus parsing, and AI service logic
• 1,500+ lines of backend tests across auth, security, realtime, and AI service paths

Deployment

• Deployed to a self-managed VPS
• Used nginx reverse proxy
• Used systemd process management
• Used Django migrations and collectstatic in deployment flow
• Used GitHub Actions backend CI with pytest
• Used GitHub Actions frontend checks where evidenced
• Used SSH-based deployment workflow
• Used Docker Compose only for local Postgres/Redis development dependencies, not production containerization

Outcome / Current Status

Didactpal was delivered as a production classroom engagement product that demonstrates backend architecture, AI integration, live WebSocket workflows, secure authentication, Flutter client delivery, testing, and VPS deployment ownership.

What I'd Improve Next

• Add stronger observability and error tracking
• Improve teacher analytics around quiz performance and student participation
• Add richer quiz editing and version history
• Add more robust content validation before AI-generated questions are used live
• Consider background job processing for larger uploads or long-running AI generation if needed
• Improve deployment hardening and rollback documentation