Vom Upload zum Stream: eine Medienplattform verteilen
Uploads, Hintergrundverarbeitung, HTTP-Caching und adaptives Streaming: die Architekturentscheidungen hinter einer verteilten Medienplattform.
Ein Klick auf „Abspielen“ kann Anmeldung, Rechteprüfung, Metadatenabfrage und mehrere Dateianfragen auslösen. Parallel läuft vielleicht noch eine Transkription. Web-Engineering für Medienplattformen muss diese Abläufe über Browser, Netzwerk und Server hinweg koordinieren.
Unsere Beispielmediathek soll auch dann verständlich bleiben, wenn ein Teil dieser Arbeit länger dauert oder fehlschlägt. Dafür lohnt es sich, drei Abläufe getrennt zu betrachten: die Verwaltung des Medienobjekts, seine Verarbeitung und die eigentliche Auslieferung.
Eine Schnittstelle beschreibt mehr als JSON
REST ist ein Architekturstil mit mehreren Bedingungen, darunter Client-Server-Trennung, zustandslose Interaktionen, Cachefähigkeit und eine einheitliche Schnittstelle. Zustandslos bedeutet dabei nicht, dass der Server keine Daten speichern darf. Eine Anfrage soll die zu ihrer Bearbeitung erforderlichen Informationen enthalten, ohne auf einen impliziten Sitzungsablauf angewiesen zu sein. Die bloße Verwendung von HTTP und JSON macht eine API noch nicht vollständig REST-konform. Fielding, 2000: Architectural Styles and the Design of Network-based Software Architectures, Kapitel 5
Im Entwurf der Mediathek würde ein Video eine eigene Identität erhalten. Seine Metadaten könnten bereits abrufbar sein, während eine Verarbeitung noch aussteht. Ein zusätzlicher Auftrag beschreibt den Fortschritt der Transkription. Der Browser muss dadurch keine einzelne Anfrage minutenlang offenhalten, um irgendwann ein fertiges Ergebnis zu bekommen.
Die Oberfläche könnte den Auftrag regelmäßig abfragen oder Änderungen über einen geeigneten Ereigniskanal empfangen. Welche Variante sinnvoll ist, hängt unter anderem von der erforderlichen Aktualität und dem Betriebsaufwand ab. Für einen ersten Prototyp wäre eine einfache Statusabfrage leichter zu überprüfen.
Wiederholung darf keine zweite Wahrheit erzeugen
Angenommen, der Server hat einen Upload gespeichert. Danach bricht die Verbindung ab, bevor die Bestätigung im Browser ankommt. Ein erneuter Versuch ist aus Sicht des Clients plausibel. Ohne Gegenmaßnahme entstehen zwei Medienobjekte.
Ein möglicher Entwurf vergibt deshalb eine eindeutige Kennung für den logischen Uploadvorgang. Der Server speichert diese Kennung zusammen mit dem Ergebnis und erkennt Wiederholungen. Dieselbe Kennung mit widersprüchlichem Inhalt müsste zurückgewiesen werden. Wie lange Kennungen aufbewahrt werden, gehört ebenfalls zum Vertrag.
Die Hintergrundverarbeitung benötigt eine ähnliche Überlegung. Ein erneut zugestellter Auftrag soll ein bereits erzeugtes Transkript nicht unkontrolliert duplizieren. Dafür kann eine Kombination aus Medienversion und Verarbeitungsversion als fachlicher Schlüssel dienen. Die Datenbankperspektive in Teil 4 ergänzt die dafür nötigen Eindeutigkeitsregeln.
Warum Videos in Segmenten ausgeliefert werden
HTTP Live Streaming, HLS, beschreibt Medienwiedergabelisten und einzelne Segmente. Unterschiedliche Varianten können verschiedene Datenraten anbieten. Ein Player kann dadurch auf veränderte Netzwerkbedingungen reagieren. Segmentierung, Pufferung und Variantenwahl beeinflussen gemeinsam Startverzögerung und Unterbrechungen. RFC 8216 dokumentiert die grundlegende Struktur dieses Verfahrens. Pantos und May, 2017: RFC 8216, HTTP Live Streaming
Für die Beispielmediathek wäre die Entscheidung von der Zielgruppe abhängig. Ein kleiner interner Bestand kann mit einer einfachen Dateiauslieferung beginnen. Bei unterschiedlichen Geräten und schwankenden Verbindungen könnten mehrere vorbereitete Wiedergabevarianten sinnvoll sein. Die zusätzlichen Dateien verursachen Speicher- und Verarbeitungsaufwand, der gegen den Nutzen abgewogen werden muss.
Eine schlechte Verbindung lässt sich außerdem nicht allein durch eine kleinere Videodatei lösen. Der Player muss seinen Zustand verständlich anzeigen und nach Unterbrechungen sinnvoll fortsetzen. Hier treffen die technische Auslieferung und die UX-Evaluation aus Teil 3 aufeinander.
Caching braucht eine fachliche Entscheidung
HTTP-Caches speichern geeignete Antworten zwischen. Frischeinformationen und Validierung steuern, wann eine gespeicherte Antwort wiederverwendet werden darf. Dabei unterscheiden sich öffentliche Medien von personalisierten Antworten. Die zugehörigen Regeln und Header beschreibt RFC 9111. Fielding, Nottingham und Reschke, 2022: RFC 9111, HTTP Caching
Für unsere Mediathek könnten unveränderliche Vorschauen versionsbezogene Adressen erhalten. Nach einer Änderung entsteht eine neue Adresse. Eine persönliche Sammlung benötigt dagegen andere Regeln, weil ihre Antwort vom angemeldeten Konto abhängt. Ein gemeinsamer Cache darf diese Unterscheidung nicht verlieren.
Ein Content Delivery Network kann die Auslieferung näher an die Nutzenden bringen. Es ersetzt aber weder die Rechteprüfung noch ein Löschkonzept. Im Projekt müsste nachvollziehbar sein, welche Kopien entstehen und wie gesperrte Inhalte aus dem Zugriff verschwinden.
Verzögerte Aktualität sichtbar machen
Ein Video kann gespeichert sein, bevor der Suchindex aktualisiert wurde. Für den Beispielentwurf wäre diese Verzögerung akzeptabel, wenn die Oberfläche sie erklärt. Bei Zugriffsrechten wäre eine veraltete Entscheidung dagegen keine ausreichende Grundlage für die Auslieferung.
Deshalb würde die Mediathek Berechtigungen an den tatsächlichen Zugriffspunkten prüfen. Ein alter Indexeintrag dürfte auch keine vertrauliche Textvorschau an eine unberechtigte Person ausgeben. Das betrifft bereits die Suche, nicht erst den Player.
Für die Fehlersuche bekämen Upload, Verarbeitung und Indexierung zusammengehörige Kennungen. Damit ließe sich der Weg eines Medienobjekts nachvollziehen, ohne vollständige Transkripte in technische Protokolle schreiben zu müssen. Die Medienverarbeitung in Teil 7 liefert die Dateien und Zeitmarken, die diese Plattform schließlich transportiert.