# Polska Lokalnie

Aplikacja do ogloszen sprzedazy i wynajmu mieszkan, domow oraz apartamentow.

## Stack technologiczny

- Backend: Java 21, Spring Boot, Spring Web, Spring Data JPA, Bean Validation
- Frontend: React, TypeScript, Vite
- Baza danych: PostgreSQL
- Reverse proxy i statyczny frontend: Nginx
- Uruchamianie: Docker Compose

## Uruchomienie w Dockerze

Skopiuj konfiguracje srodowiskowa i uruchom caly stack:

```bash
cp .env.example .env
docker compose up --build
```

W PowerShell mozesz uzyc:

```powershell
Copy-Item .env.example .env
docker compose up --build
```

Aplikacja bedzie dostepna pod adresem:

- Frontend: http://localhost
- API: http://localhost/api/listings
- PostgreSQL: localhost:5432

## Dostep w sieci lokalnej

Aplikacja jest przygotowana do pracy z innych urzadzen w tej samej sieci Wi-Fi/LAN.

Najpierw sprawdz adres IP komputera, na ktorym uruchamiasz projekt:

```powershell
ipconfig
```

Znajdz aktywna karte sieciowa i pole `IPv4 Address`, na przyklad `192.168.1.25`.

### Docker Compose

Uruchom caly stack:

```powershell
docker compose up --build
```

Na drugim urzadzeniu w tej samej sieci wejdz w przegladarce na:

```text
http://192.168.1.25
```

Port `80` jest wystawiany na siec lokalna przez Nginx. Backend i baza danych domyslnie sa dostepne tylko lokalnie na komputerze hosta, a API jest osiagalne przez Nginx pod `/api`.

### Tryb developerski

Uruchom backend lokalnie:

```powershell
cd backend
mvn spring-boot:run
```

Uruchom frontend lokalnie:

```powershell
cd frontend
npm run dev
```

Na drugim urzadzeniu wejdz na:

```text
http://192.168.1.25:5173
```

Vite nasluchuje na `0.0.0.0`, a zapytania `/api` sa proxy do backendu na `127.0.0.1:8080`.

## Uruchomienie lokalne bez Dockera

Backend:

```bash
cd backend
mvn spring-boot:run
```

Frontend:

```bash
cd frontend
npm install
npm run dev
```

Vite przekierowuje zapytania `/api` do backendu na `http://localhost:8080`.

## Struktura projektu

```text
backend/      Spring Boot API
frontend/     React + Vite
nginx/        konfiguracja Nginx i obraz web
docker-compose.yml
```

## Jakiś testowy wpis

## Wdrozenie na produkcje

Deploy jest automatyczny: push na `main` uruchamia workflow Gitea, ktory wola
`/opt/polskalokalnie/deploy-prod.sh` na serwerze. Skrypt pobiera `main`, ustawia katalog
aplikacji dokladnie na stan repozytorium (`git reset --hard`) i przebudowuje stack.

Konfiguracja produkcyjna siedzi w `/opt/polskalokalnie/app/.env.production`, ktory jest
w `.gitignore`. Zmienne trafiaja do kontenera tylko wtedy, gdy sa wymienione w sekcji
`environment` w `docker-compose.prod.yml` - samo dopisanie ich do pliku `.env` nie wystarczy.

Reczne zmiany plikow sledzonych na serwerze sa przy kolejnym deployu nadpisywane, a ich lista
trafia do `/opt/polskalokalnie/deploy.log` jako `OSTRZEZENIE`. Poprawki nalezy wprowadzac
w repozytorium, nie na serwerze.

### Nazwa projektu Compose

Oba pliki compose maja `name: polskalokalnie`. To nie jest ozdobnik: na serwerze produkcyjnym
kazda z hostowanych aplikacji lezy w katalogu o nazwie `app`, a Compose bez tego wpisu
wyprowadza nazwe projektu z nazwy katalogu. Komenda `docker compose ...` bez `-p` wchodzila
wtedy w stack innej aplikacji i podmieniala w nim serwis `backend`.

Przy recznych operacjach na serwerze zawsze podawaj pelny zestaw parametrow:

```bash
docker compose -p polskalokalnie -f docker-compose.prod.yml --env-file .env.production ps
```

### Logowanie

Loginem jest **adres e-mail**. Nick jest nadawany automatycznie i sluzy wylacznie jako adres
profilu publicznego - nie mozna sie nim zalogowac.

Konto administratora powstaje przy pierwszym starcie z `APP_ADMIN_EMAIL` i `APP_ADMIN_PASSWORD`.
Gdy konto o tym adresie juz istnieje, haslo z konfiguracji jest ignorowane, zeby restart nie
cofal hasla zmienionego w ustawieniach konta. Awaryjne przywrocenie dostepu:
`APP_ADMIN_RESET_PASSWORD=true`, restart backendu, zalogowanie, powrot do `false`.