arpitkatiyyar/intellistudy_ai

1. High-level shape

IntelliStudy AI is a two-tier application: a React single-page frontend and an Express/Node backend API. The frontend is responsible for the user experience and stateful study UI, while the backend owns authentication, study generation, persistence, file processing, caching, and AI integration.

2. Frontend boundary

The frontend is organized around pages, reusable components, layouts, and context/services.

- pages/ holds route-level screens such as Dashboard, Study, Login, Register, Profile, History, and SessionDetails.

- components/ contains UI widgets like the flashcard player, sidebar, navbar, and question input.

- context/AuthContext.jsx indicates client-side auth state management.

- services/api.js is the API boundary from the browser to the backend.

3. Backend entry and API composition

The backend is structured as a classic Express application with a central app bootstrap and route modules.

- server.js is the process entry point.

- src/app.js likely wires middleware, routes, and shared error handling.

- Route modules split the API by domain: auth, dashboard, study, flashcard, test, analytics, and upload.

4. Request processing pipeline

Incoming requests pass through middleware before reaching controllers. The backend has explicit boundaries for:

- auth.middleware.js for protected routes and JWT verification

- rateLimit.middleware.js for request throttling

- validate.middleware.js for payload validation against schemas

This suggests a layered API where controllers stay thin and domain logic is pushed into services.

5. Authentication and session security

Auth is not just login/logout; it includes registration, OTP verification, JWT access tokens, refresh tokens, and HTTP-only cookies.

- Passwords are hashed with bcrypt.

- Refresh-token support is persisted in the database, which is reflected by the Prisma migrations.

- Redis is used for temporary authentication data such as OTPs or short-lived state.

This makes auth a distinct subsystem with both database-backed and cache-backed parts.

6. Study generation and AI orchestration

The core product feature is a study-content generation pipeline. The backend’s study-related controllers/services turn either a topic/question or extracted document text into:

- summaries

- flashcards

- multiple-choice quizzes

- analytics-friendly study data

Prompt construction and response parsing are separated into utility/service modules, which suggests the AI layer is treated as an external dependency rather than embedded business logic.

7. LLM integration boundaries

The repository supports multiple AI backends: Ollama/Llama 3 and Google Gemini.

- gemini.service.js and aiService.service.js imply an abstraction over model providers.

- promptBuilder.js and extractJSON.js indicate the app expects structured model output and normalizes it before persisting or returning it.

This abstraction is important in the diagram: the app’s AI layer sits behind a service boundary, not directly inside controllers.

8. Document upload and text extraction flow

Uploaded study materials are handled separately from plain question input.

- upload.controller.js and config/multer.js manage file ingress.

- utils/pdfExtractor.js, utils/documentExtractor.js, and the README’s support for PDF/DOCX/TXT show a text-extraction pipeline.

- The uploads/ directory is a local filesystem staging area.

After extraction, the text is fed into the same AI generation flow as manual prompts.

9. Persistence layer and domain model

Prisma is the ORM boundary between the backend and MySQL.

- prisma/schema.prisma and multiple migrations show the database is actively used for app state, not just auth.

- Migration names reveal key entities/features such as flashcard progress, cascade deletes, and refresh tokens.

This suggests persisted study sessions, user-linked flashcards, token records, and progress tracking are central to the data model.

10. Learning features as separate backend domains

The backend splits the learning experience into functional subsystems:

- Flashcards: review, known/difficult marking, progress tracking

- Tests/Quizzes: MCQ generation and answer checking

- Study sessions: creation, history, and session detail retrieval

- Analytics: mastery percentage, weak-topic detection, and aggregate stats

- Dashboard: summary metrics for the user’s study activity

These are distinct API domains, even though they share the same user/session data.

11. Redis as a performance and ephemeral-state layer

Redis is used for more than generic caching. The README and config layout imply it supports:

- document analysis cache

- OTP storage

- temporary authentication/session data

- faster repeat AI requests

In the architecture diagram, Redis should be shown as an auxiliary store alongside MySQL, not as the primary system of record.

12. What to show as the main boundaries

For an architecture diagram, the most important boundaries are:

- Browser / React UI

- Express API layer

- Middleware/security gate

- AI orchestration layer

- File extraction pipeline

- Prisma/MySQL persistence

- Redis ephemeral cache

- External/local model providers (Ollama, Gemini)

- Local uploads storage

The main data flows are: user input or uploaded document → backend validation/auth → text extraction or prompt building → AI generation → structured response → persistence → analytics/history returned to the frontend.