morz-infoboard/docs/SERVER-KONZEPT.md

Info-Board Neu - Server-Konzept

Ziel

Der Server ist die zentrale Steuer- und Verwaltungsinstanz der Plattform.

Er soll:

• Benutzer, Firmen und Screens verwalten
• Medien und Playlists bereitstellen
• globale Templates und Kampagnen steuern
• Provisionierung neuer Screens ausloesen
• Status, Screenshots und Heartbeats sammeln
• MQTT und HTTPS sauber trennen

Grundprinzip

Der Server ist die Quelle der fachlichen Wahrheit.

Der Player bleibt trotzdem lauffaehig, wenn der Server temporaer nicht erreichbar ist.

Das bedeutet:

• Server verwaltet Konfiguration und Inhalte zentral
• Player fuehrt lokal und robust aus
• Server sendet Steuerimpulse, Player synchronisiert aktiv nach

Hauptkomponenten

Reverse Proxy

Aufgaben:

• TLS-Terminierung
• Routing fuer API und Web-UIs
• optionale Auth-/Header-Regeln

Backend-API

Bevorzugte Sprache:

• Go

Aufgaben:

• Authentifizierung und Autorisierung
• CRUD fuer Tenants, Users, Screens, Medien, Playlists
• Verwaltung globaler Templates und Kampagnen
• Player-Sync-Endpunkte
• Speicherung von Status und Screenshots
• Start von Provisionierungsjobs

Admin-UI

Aufgaben:

• Gesamtübersicht aller Screens
• Vorschau und Status
• Template-/Kampagnenverwaltung
• Kommandos und Provisionierung

Tenant-UI

Aufgaben:

• Uploads und Medienverwaltung pro Firma
• Pflege der monitorbezogenen Playlist
• Vorschau des eigenen Screens

Datenbank

Empfehlung:

• PostgreSQL

Aufgaben:

• Speicherung fachlicher Daten
• Status, Jobs, Revisionen, Zuordnungen

MQTT-Broker

Empfehlung:

• Mosquitto

Aufgaben:

• Heartbeats
• Statusmeldungen
• Events
• Kommandos und ACKs

Dateispeicher

Aufgaben:

• Uploads
• Screenshots
• ggf. serverseitig vorbereitete Medien

V1:

• Dateisystem ausreichend

Fachliche Bereiche

1. Mandanten und Benutzer

Der Server trennt:

• globale Admins
• tenantgebundene Nutzer

Regel:

• Firmen sehen nur ihren Bereich
• Admins sehen alles

2. Screen-Verwaltung

Der Server kennt jeden Screen mit:

• ID
• Name
• Klasse
• Orientierung
• Rotation
• Tenant-Zuordnung
• technischem Registrierungsstatus

3. Medienverwaltung

Der Server verwaltet:

• Uploads
• externe Medienreferenzen
• Metadaten
• tenant- oder screenspezifische Zuordnung

4. Playlist-Verwaltung

Der Server verwaltet tenantbezogene Inhalte pro Screen.

Wichtige Felder:

• Reihenfolge
• Dauer
• valid_from
• valid_until
• Fehlerstrategie
• Cache-Politik

5. Template- und Kampagnenverwaltung

Der Server stellt den globalen Orchestrierungsbereich bereit.

Funktionen:

• Templates erstellen
• Szenen pflegen
• Zielgruppen waehlen
• Kampagnen aktivieren/deaktivieren
• Zeitfenster setzen
• Uebersteuerung sichtbar machen

6. Provisionierung

Der Server startet Provisionierungsjobs fuer neue Screens.

Aufgaben:

• Eingaben aus Admin-UI entgegennehmen
• Job anlegen
• Secret-Handling absichern
• Worker oder Jobrunner starten
• Fortschritt speichern
• Fehler sauber rueckmelden

API-Bereiche

Die API soll mindestens diese Domänen haben:

• auth
• tenants
• users
• screens
• media
• playlists
• templates
• campaigns
• player
• commands
• provisioning

Revisionsmodell

Der Server arbeitet mit Revisionen, damit Player effizient synchronisieren koennen.

Mindestens:

• config_revision
• playlist_revision
• media_revision
• campaign_revision

Status- und Vorschaukonzept

Der Server speichert:

• letzten bekannten Heartbeat
• letzten Status
• letzten Screenshot
• aktuelle Inhaltsquelle pro Screen

Die Admin-UI soll damit erkennen:

• online/offline
• normaler tenantbezogener Betrieb
• globale Kampagnen-Uebersteuerung
• Fallback-Betrieb
• Fehlerzustand

Provisionierungsjobrunner

Die Provisionierung soll nicht direkt in Web-Requests laufen.

Stattdessen:

• API legt Job an
• dedizierter Worker/Jobrunnner arbeitet ihn ab
• Fortschritt wird in DB gespeichert

Docker-Compose-Zielbild

Sinnvolle Komponenten in compose/:

• reverse-proxy
• backend
• postgres
• mosquitto
• optional worker

Sicherheitsgrundsaetze

• Root-Bootstrap-Geheimnisse nur kurzlebig oder referenziert speichern
• API- und MQTT-Zugaenge getrennt behandeln
• alle Admin-Kommandos auditieren
• Tenant-Trennung strikt serverseitig erzwingen

Zielstruktur im Repo

Empfohlene Unterstruktur fuer den Server:

• server/backend/
• server/admin-ui/
• server/tenant-ui/
• server/worker/
• compose/

Testfaelle fuer den Server

• Tenant sieht nur eigene Daten
• Admin sieht alle Daten
• Kampagne ueberschreibt tenantbezogenen Content korrekt
• Screen-Provisionierung legt Job sauber an
• Player-Sync ueber Revisionen funktioniert
• MQTT-Kommandos werden protokolliert
• Screenshot-Upload erscheint im Admin-Dashboard