Иди на текст

Roadmap

Plan razvoja Ordify platforme. Roadmap održava Dažbog (project manager agent) u saradnji sa Matijom.

Odluke (zaključene dogovorom)

  • Baze: database-per-service — svaki servis ima svoju logičku bazu (meni, porudzbine, zone + keycloak). U dev: 1 PostgreSQL kontejner sa 4 baze. U produkciji (Faza 2+): PG instanca po servisu, kroz K8s StatefulSet.
  • Skaliranje baze: ne projektujemo za sharding. Redosled poteza kad instanca poraste: dobri indeksi → particionisanje/arhiviranje → read replike → PgBouncer → sharding po tenantu (nikad kružni). Ordify je on-prem po klijentu — svaka instanca je prirodni shard.
  • Redis: ne uvodimo kao keš — geofencing već ima in-memory keš, meni je mali, order mora biti konzistentan. Redis (pub/sub) dolazi tek sa notification-service-om i multi-pod deploymentom.
  • Keycloak: verzija 26.7, PostgreSQL storage, realm ordify. Klijenti: ordify-backend (confidential) + ordify-admin, ordify-kitchen, ordify-customer (public). Role: ADMIN, KITCHEN, CUSTOMER. Dev korisnici: admin@ordify.dev, kitchen@ordify.dev, customer@ordify.dev (usernames: admin, kitchen, customer).
  • Docker Compose: više fajlova — docker-compose.yml (osnova) + .dev.yml + .prod.yml.
  • Docker slike servisa: native (GraalVM/Mandrel) — brz startup, mali RAM, idealno za K8s. Lokalni dev ostaje JVM (quarkus:dev).
  • licence-service: novi servis za licenciranje (aktivacija instanci, ključevi, subscription paketi) — planiran za Fazu 2.

Faze

Faza 1 — Infrastruktura i osnove ✅ (kompletirana)

  • [x] Analiza projekta i dokumentacija
  • [x] MkDocs sajt sa dokumentacijom
  • [x] Uklanjanje geofencing duplikata iz order-servisa
  • [x] Docker Compose — baze + Keycloak (postgres 18.4, keycloak 26.7) + dinamički portovi kroz .env
  • [x] Keycloak realm ordify (klijenti, role, korisnici) + import iz fajla
  • [x] OIDC integracija u servisima (menu, order, geofencing) + testovi sa mock JWT
  • [x] Datasource servisa na infra baze (meni/porudzbine/zone) kroz POSTGRES_* env var-ove
  • [x] CI/CD — build + test + native slike → GHCR na push/PR + cleanup (latest + 2 verzije)
  • [x] Micrometer metrike u servisima (quarkus-micrometer-registry-prometheus, /q/metrics)
  • [x] Monitoring stack — Prometheus v3.13.2 + Grafana 13.1 (dashboard + alert rules provisioning)
  • [x] Discord webhook alerting — live test: gašenje servisa → 🔴 PROBLEM / 🟢 REŠENO
  • [x] Smoke-test skripta (scripts/smoke-test.sh) — 17 provera, za svaku klijentsku instancu
  • [x] GHCR cleanup sa ličnim PAT (GHCR_CLEANUP_TOKEN, delete:packages + workflow scope)
  • [x] Env-driven konfiguracija — nula hardkodovanih portova/adresa (.env = jedan izvor istine)

Napomene iz Faze 1 (prenose se u Fazu 2): - Keycloak dev hostname: host.docker.internal:PORT (jedan issuer za browser i servise; underscore nije dozvoljen u plain hostname — koristi se URL format http://...) - Git tagove kreira isključivo lični PAT (GITHUB_TOKEN nikad nema workflows permisiju) - Grafana template funkcije: samo Go built-in (or, index…) — Sprig (default) ne postoji - Alert "servis ne odgovara": threshold lt 1 na up == 0 (obrnuta logika gt 0 nikad ne pali) - Windows/Docker Desktop: curl -4 (Docker forwarduje samo IPv4), Git Bash CRLF trim

Faza 2 — Notification, licence i povezivanje ⏳ (plan odobren)

Redosled (dogovor od 11.08.): OpenBao prvo → notification-service → Redis sloj → prod priprema → licence-service

  • [ ] Blok 1: OpenBao (Vault) — centralno skladište secreta (PG lozinke, Keycloak klijenti, webhook URL, Redis). Compose + unseal + servisi čitaju iz OpenBao-a umesto .env. Rano uveden da novi servisi od starta koriste vault.
  • [ ] Blok 2: notification-service — WebSocket (kuhinja šalje statuse), OIDC zaštita, metrike, CI/CD, smoke test
  • [ ] Blok 3: Redis sloj — Redis Streams (ne Pub/Sub — poruke se čuvaju dok primalac ne potvrdi, garantovana isporuka i kad oba servisa padnu). order → Redis → notification
  • [ ] Blok 4: Prod priprema — Flyway migracije umesto drop-and-create, docker-compose.prod.yml, instalacija na suvo
  • [ ] Blok 5: licence-service — monthly subscription model (aktivacija, ključevi, obnova)

Odluke Faze 2 (zaključene): - WebSocket (ne SSE) — kuhinja šalje statuse nazad - Redis Streams za order → notification (garantovana isporuka, Pub/Sub baca poruke) - OpenBao (HashiCorp Vault community fork) umesto .env za secrete - Flyway (ne Liquibase) — samo PostgreSQL, čist SQL, Quarkus integracija - Servisna diskoverija (Stork+Consul) sačekaće K8s — za jednu on-prem mašinu je dodatna težina bez koristi - licence: monthly based

Faza 3 — Frontend ekrani

  • [ ] Admin panel (web) — meni, zone, porudžbine, statistika
  • [ ] Kuhinjski ekran (web, real-time) — nove porudžbine, statusi
  • [ ] Sajt kupca (web) — meni, poručivanje, praćenje statusa

Faza 4 — Dodaci (subscription model)

  • [ ] Online plaćanje (paket Premium)
  • [ ] Loyalty program / Rule engine (popusti, bodovi)
  • [ ] Mobilna aplikacija (kupac)
  • [ ] Subscription/billing sistem za klijente (restorane)

Vremenske procene (grupno, radni dani)

Faza Procena
Faza 1 2–3 nedelje
Faza 2 2–3 nedelje
Faza 3 10–14 nedelja
Faza 4 8–12 nedelja

Note

Procene su okvirne i zavise od raspoloživosti. Dažbog prilagođava plan prema stvarnom tempu rada.