00adasod/liaprojekt

1. Repository shape

- This is a two-tier application: a Spring Boot backend in Backend/ and a React + TypeScript frontend in Frontend/.

- The root also contains deployment/configuration files and documentation artifacts (.github/workflows/deploy.yml, staticwebapp.config.json, JIN24/, MOV24/).

2. Backend entry point and runtime

- The backend is a standalone Java application started from se.liaprojekt.LiaProjektApplication.

- The presence of pom.xml, Maven wrapper files, and application.properties indicates a conventional Spring Boot + Maven runtime.

3. API boundary

- HTTP endpoints are grouped into controllers: UserController, CourseController, AiController, and HealthCheckController.

- CorsConfig shows the backend is explicitly configured to accept browser requests from the frontend origin, so the frontend-backend split is a real network boundary.

4. Domain model boundary

- The backend domain is organized around a few feature areas:

- Course content: Course, Section, Material

- Assessment/testing: TestQuestion, TestAnswer, TestResult

- User and progress: User, UserProgress, AnsweredQuestion

- AI support: AiCharacter, AiSession

- Notifications: EmailNotification

- These are the core entities that likely map to persisted data and API payloads.

5. Persistence layer

- Repositories such as CourseRepository, UserRepository, SectionRepository, AiSessionRepository, AiCharacterRepository, UserProgressRepository, TestResultRepository, and EmailNotificationRepository indicate the backend uses a repository-based persistence layer.

- Because there is no visible service/ package, the architecture appears controller-centric, with controllers likely coordinating business logic directly with repositories and entities.

6. DTO and API contract layer

- CourseRequest, CourseResponse, UserRequest, and UserResponse define explicit request/response shapes.

- This separates external API contracts from internal entity models, which is important for keeping the frontend insulated from persistence details.

7. Error handling and robustness

- The backend includes a centralized exception subsystem: GlobalExceptionHandler, ErrorResponse, BadRequestException, ConflictException, and ResourceNotFoundException.

- This means errors are normalized at the API boundary rather than handled ad hoc in individual controllers.

8. AI feature subsystem

- AiController, AiCharacter, AiSession, and AnsweredQuestion suggest a dedicated AI-assisted learning flow.

- Architecturally, this is a distinct feature path alongside courses/users, likely maintaining conversational or session state separate from course content and progress tracking.

9. Frontend structure

- The frontend is a Vite-powered React app (vite.config.ts, main.tsx, App.tsx) written in TypeScript.

- src/services/api.ts acts as the single client-side integration point to the backend API.

- UI components are sparse and feature-oriented, including HealthCheck.tsx and Message.tsx, suggesting a small app surface with backend-driven data.

10. Frontend-backend data flow

- The browser renders the React app, which calls backend endpoints through src/services/api.ts.

- Backend controllers validate and process the request, interact with repositories/entities, and return DTO-based JSON responses.

- The frontend likely consumes these responses directly for course/user/AI interactions.

11. Health and connectivity

- HealthCheckController on the backend and HealthCheck.tsx on the frontend indicate a built-in connectivity or readiness check across the deployment boundary.

- This is useful both for user-facing status and for deployment/runtime verification.

12. Testing and quality boundary

- Backend tests exist for startup plus controller behavior: LiaProjektApplicationTests, CourseControllerTest, and UserControllerTest.

- This shows the main automated verification focuses on application boot and API endpoints rather than isolated service-layer tests, which fits the visible controller-heavy structure.

13. Deployment and hosting

- .github/workflows/deploy.yml indicates CI/CD automation.

- staticwebapp.config.json strongly suggests the frontend is deployed as a static web app with route handling/configuration at the edge, while the backend is deployed separately or as a paired backend service.

14. Documentation/analysis assets

- JIN24/ contains design artifacts such as architecture, requirements analysis, ER diagrams, and class diagrams.

- These are not runtime components, but they likely capture the intended domain model and are useful references when drawing an architecture diagram.