morz-infoboard/server/backend
Jesko Anschütz e03948f25d Kopplung Agent↔Backend: Selbstregistrierung + Playlist-Rotation
Backend:
- ScreenStore.Upsert(): idempotentes INSERT ON CONFLICT für Self-Registration
- POST /api/v1/screens/register: Agent registriert sich beim Start (upsert)
- manage/register.go: neuer Handler, immer unter Tenant "morz"

Agent:
- config: screen_name + screen_orientation (mit Fallback auf screen_id / landscape)
- app.go: registerScreen() — POST /api/v1/screens/register beim Start (Retry 30s)
- app.go: pollPlaylist() — GET /api/v1/screens/{slug}/playlist alle 60s
- app.go: nowFn liefert Playlist statt statischer URL; PlayerContentURL als Fallback
- playerserver: PlaylistItem-Struct in NowPlaying; JS rotiert Items per duration_seconds
- JS: Playlist-Fingerprint verhindert Reset laufender Rotation bei unverändertem Stand

Ansible:
- config.json.j2: screen_name + screen_orientation ergänzt
- host_vars/info10: screen_name + screen_orientation
- host_vars/info01-dev: screen_name + screen_orientation

Kopplung per Konvention: screen_id (config.json) = slug (DB)
Beim ersten Neustart der Agents erscheinen die Bildschirme automatisch im Admin-UI.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-23 05:57:58 +01:00
..
cmd/api Lege Entwicklungsleitfaden und Go-Gerueste an 2026-03-22 13:42:00 +01:00
internal Kopplung Agent↔Backend: Selbstregistrierung + Playlist-Rotation 2026-03-23 05:57:58 +01:00
Dockerfile Bugfixes: JSON-Tags, Tenant-Lookup, Dockerfile Go-Version 2026-03-22 23:26:56 +01:00
go.mod Baue Ebene 2: PostgreSQL-Backend, Medien-Upload und Playlist-UI 2026-03-22 22:53:00 +01:00
go.sum Baue Ebene 2: PostgreSQL-Backend, Medien-Upload und Playlist-UI 2026-03-22 22:53:00 +01:00
README.md Baue Layout-Resolver und lokale Entwicklungsgerueste aus 2026-03-22 16:03:21 +01:00

Backend

Dieses Verzeichnis enthaelt das erste Geruest fuer das zentrale Backend.

Ziel fuer die erste Ausbaustufe:

  • HTTP-API in Go
  • Health-Endpunkt
  • saubere Projektstruktur fuer spaetere API-, Worker- und Datenbankmodule
  • erste serverseitige Aufloesungslogik fuer message_wall

Geplante Unterstruktur:

  • cmd/api/ fuer den API-Startpunkt
  • internal/app/ fuer App-Initialisierung
  • internal/campaigns/ fuer Kampagnen- und Template-Logik
  • internal/httpapi/ fuer HTTP-Routing und Handler
  • internal/config/ fuer Konfiguration

Aktuell vorhanden:

  • GET /healthz
  • GET /api/v1
  • GET /api/v1/meta
  • POST /api/v1/tools/message-wall/resolve als erste serverseitige Layout-Aufloesung fuer message_wall
  • einheitliches API-Fehlerformat im HTTP-Layer