n-xus-ll/web-app

1. This repository is a full-stack web application with three main runtimes: a React/Vite frontend, a Kotlin/Ktor backend, and a PostgreSQL database. The backend is organized as a multi-module Gradle project under backend/ktor-backend.

2. The frontend lives in frontend/ and is a single-page app built with React. It contains page-level views for items, loans, users, locations, statistics, profiles, login/register, and a map page. The UI is split into reusable components, a map context, and service wrappers that call backend APIs.

3. The backend server module is the main application runtime. It uses Ktor for HTTP routing, serialization, logging, and likely WebSocket/RPC support. Entry points and bootstrap are in server/src/main/kotlin/main.kt, Routing.kt, Http.kt, Serialization.kt, and Resources.kt.

4. The backend is layered: routes/controllers live in routes/ and features/*/*Routes.kt, business logic is in feature services such as LoansService, and persistence is abstracted through repository/ plus database/ entity/mapper/table definitions. This is a classic API → service → repository → database flow.

5. The primary business domains are items, loans, users, and locations. Each domain has its own route/model files, and there are database tables and DTO/entity classes for items, locations, users, and lookup/reference data like categories, item conditions, and damage policies.

6. Authentication is handled on the backend in auth/ with JWT support. The frontend has dedicated auth services and protected routing (PrivateRoute.jsx), so the app likely uses token-based session state passed between client and server.

7. PostgreSQL is the persistent store. The schema is defined in database/schema.sql and seeded via database/seed.sql, while the backend’s database/tables/* and database/*Mapper.kt files map the relational schema into application objects.

8. There is a Kotlin DSL subsystem in server/src/main/kotlin/dsl/ with lexer, parser, AST, semantic analyzer, interpreter, and GeoJSON export. That means the backend accepts a custom query or scripting language, validates it, executes it, and can convert results into geospatial output.

9. Spatial/geographic data is a first-class concern. The backend has geo-point models, parsers/formatters, GeoJSON utilities, and a MapPage plus geocoding service on the frontend. This suggests map-based item/location visualization and location lookup are key features.

10. The core module provides shared contract code: service interfaces, request/response models, and common types such as GeoPoint, LoginRequest, and UserResponse. This module is shared between client and server to keep API/data contracts aligned.

11. The client module is a Kotlin RPC client built around the shared core. Its presence, along with kotlinx-rpc dependencies and Rpc.kt files on both client and server, indicates a typed RPC layer in addition to or alongside the HTTP API.

12. Operationally, the repo is containerized. There are Dockerfiles for both frontend and backend, Docker Compose files at the repo root, and a GitHub Actions workflow for deployment. The frontend also uses Nginx for production serving.

13. The backend includes tests for HTTP/RPC behavior and the DSL interpreter. That implies the more complex boundaries being validated are the API layer, remote contract layer, and custom query language rather than the React UI.

14. For diagramming, the core data flow is: browser UI → frontend service layer → backend routes/RPC → domain services → repositories/ORM tables → PostgreSQL, with side paths for auth/JWT, DSL execution, and geospatial conversion/GeoJSON output.