push-pray/quizzer

1. Overall shape

- This is a single monorepo with two main runtime pieces: a Spring Boot backend in src/main/java and a React + TypeScript frontend under src/main/resources/Quizz.

- In development, the frontend runs as a separate Vite app; in deployment, it is packaged alongside the backend and served from the same codebase.

2. Backend boundary

- The backend exposes the application’s core quiz functionality through REST controllers in com.example.quizzer.RESTController.

- Main API areas are categories, quizzes, questions, and reviews. The README also documents answer submission endpoints used by the quiz-taking flow.

3. Layered backend architecture

- The backend follows a standard Spring layering:

- model/: JPA entities such as Category, Quizz, Question, Review, User

- repository/: Spring Data JPA persistence interfaces

- service/: business logic and transaction orchestration

- RESTController/: HTTP entry points

- DTO/ and mapper/: API payload shaping and entity-to-DTO conversion via MapStruct

4. Core data flow

- Requests come from the frontend to a REST controller.

- The controller delegates to a service.

- The service reads/writes entities through repositories.

- Responses are usually returned as DTOs rather than raw entities, which keeps the API contract separate from persistence structure.

5. Domain model

- The central business object is the quiz (Quizz in code), which belongs to a category, contains questions, and can have reviews.

- User exists as a model, though the repo tree does not show a dedicated auth subsystem.

- The README’s ER diagram matches this: Category -> Quizz -> Question/Review.

6. Question and quiz composition

- Question is a key entity for both quiz creation and quiz-taking.

- The DTO set includes QuestionDTO, QuestionInfoDTO, QuestionResultDTO, AnswerResultDTO, OptionDTO, and quiz/teacher info DTOs, which suggests the system distinguishes:

- edit-time quiz/question representations

- student-facing quiz delivery

- result and grading views

- Mappers (QuestionMapper, QuizzMapper) bridge these representations.

7. Frontend structure

- The frontend is organized by role:

- TeacherDashboard/ for creating and editing quizzes, questions, and categories

- StudentDashboard/ for browsing published quizzes, answering questions, and reviewing results

- The app entry points are main.tsx and App.tsx, with shared API helper files such as quizzapi.ts, questionapi.ts, reviewapi.ts, and categoryapi.ts.

8. Frontend-to-backend interaction

- The React app does not appear to own business logic; it is primarily a presentation layer that calls backend REST APIs.

- Separate API helper modules encapsulate HTTP access, which keeps components focused on UI state and navigation.

- The frontend routes described in the README map directly to quiz management and quiz-taking screens.

9. Seed data and startup behavior

- SampleDataService initializes sample quizzes/questions at startup, which is important for local development and demo usage.

- This means the backend has a built-in bootstrap path for initial content rather than depending on manual database seeding.

10. Persistence and environments

- Local development uses H2 in-memory database.

- Production is configured for PostgreSQL and there is a separate application-rahti.properties, indicating deployment-specific configuration.

- The repository also includes a Dockerfile, so containerized deployment is part of the architecture.

11. Testing boundary

- Tests are focused on REST behavior and run against H2 in src/test/resources.

- The test suite includes controller tests for categories, questions, quizzes, and answer flow, which suggests the primary verification strategy is API-level integration testing rather than isolated unit tests.

12. Diagramming takeaway

- If you draw the architecture, the clearest boundaries are:

- React UI on top

- REST API layer in the Spring Boot app

- service + repository + JPA entity layers in the backend

- H2/PostgreSQL as persistence

- sample data bootstrapping as a startup-only path

- tests as a separate verification track against the API and in-memory DB