Obsah kapitoly
Čo ovplyvňuje výber technológií
Výber stacku pre národný štátny register nie je "najnovšie a najlepšie". Je to rovnica medzi piatimi faktormi:
Dlhodobá udržateľnosť
Systém bude žiť 15+ rokov. Technológia musí byť po tomto čase stále maintainovaná. Vyhýbame sa experimentálnym rámcom a závislosti na jednom dodávateľovi.
Odborná komunita v SR
Musí existovať dostatočný počet slovenských vývojárov, ktorí vedia danú technológiu. Inak vzniká dodávateľský lock-in.
Fit pre doménu
Event sourcing, heterogénna schéma (veľa druhov entít s rôznymi atribútmi), geo-dotazy pre športoviská, agregáty pre štatistiky.
Open source
Žiadne proprietárne licencie s risk of hostage. Kompletný stack je publikovateľný ako open source bez právnych prekážok.
Štandardy EÚ / SR
Súlad s Výnosom o štandardoch pre IS verejnej správy, kompatibilita s eIDAS, OpenAPI, OAuth 2.0 / OIDC, DCAT-AP.
Cloud-agnostic
Žiadny vendor lock-in na konkrétneho cloud providera. Možnosť prevádzky v on-prem aj v EÚ cloudoch.
Node.js ako backendová platforma
Jadro systému sa implementuje v Node.js v jazyku TypeScript. Voľba vychádza z troch dôvodov:
- Zdieľanie typov medzi backend a frontend. Doménový model, DTO pre API, validačné schémy (Zod) — všetko je v jednom monorepe, jedna jazyk, jedna typová definícia. Žiadne drift medzi serverom a klientom.
- Silná komunita na Slovensku. JavaScript/TypeScript je najpoužívanejšia technológia u nás, dostupnosť seniorných vývojárov je výrazne vyššia ako pre Java alebo .NET.
- Asynchrónne I/O z prvého dňa. Pre integračnú platformu s mnohými externými volaniami (RFO, RPO, MCP, webhooks) je event loop výhodou.
Konkrétne komponenty
| Vrstva | Technológia | Funkcia |
|---|---|---|
| HTTP framework | Fastify | Výkonný, low-overhead, natívna podpora JSON schema |
| Validácia | Zod | Typy + runtime validácia v jednom |
| OpenAPI | fastify-swagger + zod-to-openapi | Špecifikácia generovaná z kódu, nie naopak |
| Auth | oidc-provider | Certifikovaný OIDC provider pre OAuth 2.0 |
| Policy engine | Open Policy Agent (OPA) | Declaratívne pravidlá v jazyku Rego |
| Message queue | NATS JetStream alebo Kafka | Event streaming pre webhooks a projekcie |
| Worker jobs | BullMQ | Scheduled úlohy, retries, dead-letter |
| Logging | pino + OpenTelemetry | Štruktúrované JSON logy, distribuovaný tracing |
| Testing | vitest + supertest | Unit + integration testy |
Dátová vrstva — MongoDB
MongoDB ako primárna databáza pre event store aj pre projekcie. Výber je pragmatický — MongoDB sa pre tento typ systému správa lepšie ako klasické relačné databázy.
Prečo MongoDB a nie PostgreSQL
Flexibilná schéma
Rôzne typy eventov majú rôzne payloady. MongoDB dokumentový model to reflektuje priamo. V PostgreSQL by sme skončili pri JSONB poliach a museli schizofrenne prepínať medzi relačným a dokumentovým myslením.
Change streams
Natívny mechanizmus na sledovanie zmien. Projekčné workers sa prihlásia na events kolekciu a prepočítavajú read modely bez potreby Kafka-like systému.
Geo-dotazy
2dsphere indexy pre športoviská sú priamočiare. "Nájdi plavárne do 10 km od môjho hotela" je jeden dotaz.
Aggregation framework
Silný pipeline pre štatistiky a agregované projekcie. Často sa vyhneme external ETL.
Atlas / self-hosted
Môže sa prevádzkovať v EÚ cloude (Atlas EÚ regióny) aj on-prem (MongoDB Community Edition / Percona PSMDB).
Multi-document transactions
Od verzie 4.0 plne podporuje transakcie naprieč dokumentmi, takže ACID garantie pre kritické operácie nie sú problém.
Organizácia kolekcií
| Kolekcia | Účel | Poznámky |
|---|---|---|
events | Event store — nemenný append-only log | Index na aggregate_id, event_type, occurred_at, correlation_id |
persons | Projekcia — aktuálne osoby | Obnovované zo stream eventov |
affiliations_current | Projekcia — aktívne afiliácie | Rýchle dotazy "kto je teraz kde" |
affiliations_history | Projekcia — historické afiliácie | Time-travel dotazy, štatistika |
organizations | Projekcia — organizácie | Cache z RPO + vlastné atribúty |
facilities | Projekcia — športoviská | 2dsphere geo-index |
qualifications | Projekcia — platné kvalifikácie | TTL-aware (expirácia) |
consents | Projekcia — platné súhlasy | Indexy na person_id, purpose_code |
audit_log | Každé API volanie | 10-ročná retencia, sharding po dátume |
stats_aggregates | Vopred prepočítané agregáty | Nočné joby, denné incremental updates |
Next.js pre admin aplikácie
SportUp jadro samo nemá používateľské rozhranie — je to API. Ale prevádzkovateľ potrebuje administračné nástroje: správa certifikovaných aplikácií, pohľad do audit logu, správa číselníkov, správa Purpose Catalogue, dashboard pre nasadenie a incidenty. A samotná dotknutá osoba potrebuje portál, kde vidí svoje dáta, udelené súhlasy a môže ich spravovať.
Pre tieto aplikácie je Next.js dobrá voľba:
- React Server Components — časť UI sa renderuje na serveri s prístupom k databáze, časť klientsky. Citlivé dáta sa ľahko držia server-side.
- Route handlers pre BFF — Backend for Frontend pattern natívne. Klient neimplementuje zložité OAuth flow, len volá svoj vlastný BFF.
- TypeScript full-stack — zdieľaný doménový model s backendom, bez potreby code generation.
- App Router + Streaming — moderné vzory pre low-latency používateľské zážitky.
Aplikácie postavené na Next.js
Admin portál prevádzkovateľa
Správa aplikácií, scopes, audit, incidenty, health dashboards.
Portál dotknutej osoby
Prehľad vlastných dát, consent dashboard, GDPR práva, verifikačné tokeny.
Developer portál
Dokumentácia API, interaktívny OpenAPI explorer, sandbox prostredie, playground.
Open data portál
Verejná mapa športovísk, katalóg podujatí, vizualizácie štatistík.
Aplikácie zväzov a klubov
Zväzy a kluby si stavajú svoje vlastné aplikácie podľa vlastných potrieb. SportUp im poskytuje API, SDK a dokumentáciu. Niektoré použijú Next.js, iné .NET, PHP alebo React Native pre mobil — to je ich rozhodnutie. SportUp nediktuje frontend stack tretím stranám.
Doplnkové komponenty
Redis
Cache pre policy engine rozhodnutia, rate limiting (token bucket), session store pre OIDC, dočasné verifikačné tokeny.
OpenSearch / Elasticsearch
Full-text vyhľadávanie osôb a organizácií, fuzzy match pre Identity Resolution, agregácie pre dashboardy.
MinIO alebo S3-kompatibilný
Dokumenty (zdravotné prehliadky, fotky, scany licencií) s lifecycle managementom a end-to-end šifrovaním.
HashiCorp Vault
Správa šifrovacích kľúčov, secrets rotation, zabezpečenie dešifrovania citlivých polí (napr. rodné číslo).
Grafana + Prometheus + Loki
Monitoring, metriky, logy. SLO dashboards, alerting pre prevádzkový tím.
Temporal.io
Orchestrácia dlhotrvajúcich sag (prestupy, overenia, CSRÚ synchronizácia). Retries, checkpointy, auditovateľnosť.
Nasadenie a prevádzka
Kontajnery a orchestrácia
Celý systém je kontajnerizovaný (Docker) a orchestrovaný cez Kubernetes. Pre štátny systém odporúčame EÚ cloud s compliance certifikáciami (IL4, ENISA, ISO 27001) alebo hybridný model (citlivé dáta on-prem, webové vrstvy v cloude).
CI/CD
GitLab alebo GitHub Actions. Každý merge cez pull request, code review, povinné testy, automatické nasadenie do staging. Produkčné deployment-y vyžadujú manuálne schválenie odpovedajúcich rolí.
Disaster recovery
| Parameter | Hodnota | Stratégia |
|---|---|---|
| RPO | 5 minút | MongoDB replica set + cross-region replication |
| RTO (čítanie) | 30 minút | Multi-AZ cluster, automatic failover |
| RTO (zápis) | 2 hodiny | Warm standby cluster v sekundárnej lokalite |
| Archivácia eventov | nekonečná | Event store je nemenný, nič sa nemaže |
| Backup audit logov | 10 rokov | Cold storage, WORM režim |
Postupné budovanie
Systém sa nedá postaviť "big bang" — ide o niekoľkoročný projekt s postupným nasadením modulov. Navrhujeme šesť fáz:
Základ identity
Person, Organization, Identity Broker, napojenie na RFO/RPO. Minimálne API. 4–6 mesiacov.
Afiliácie a číselníky
Affiliation ako event-sourced agregát, centrálne číselníky, policy engine. Pilotný zväz. 4–6 mesiacov.
Consent a GDPR
Purpose Catalogue, consent management, portál dotknutej osoby. 3–4 mesiace.
Športoviská a podujatia
Katalóg športovísk, kalendár podujatí, otvorené dáta. 4–6 mesiacov.
MCP a rozšírené integrácie
MCP servery, webhooks, event stream, integrácie s externými platformami (cestovný ruch). 3–4 mesiace.
Decommission starého ISŠ
Presun relevantných historických dát z existujúceho ISŠ do SportUp (nie ako RPOS/RFOS, ale vo forme novej dátovej štruktúry). Paralelná prevádzka počas prechodu, následne vypnutie starého systému. 6–12 mesiacov.
Od prvého dňa otvorené
Už od fázy 1 sú dáta publikované ako open data a dokumentácia je verejná. Zväzy a komerční partneri môžu participovať od začiatku, ich spätná väzba formuje ďalšie fázy.
Čo ďalej
Tento dokument je otvorený návrh. Privítame spätnú väzbu od národných zväzov, kluby, územnej samosprávy, úradov verejnej správy, športovej a výskumnej komunity.
Dokumentácia bude ďalej doplňovaná o:
- Kompletnú OpenAPI 3.1 špecifikáciu s príkladmi
- Kompletný Purpose Catalogue vo formáte Excel a YAML
- Ukážkové implementácie klientov (TypeScript SDK, Python SDK)
- Referenčnú implementáciu pilotného zväzu
- Migračné scenáre z existujúceho IS športu