Ich entwickle eine App mit mehreren Musikwiedergabelisten, einer Ansicht für jede Playlist und einem Player.

Ich verwende bereits die HTML5-Verlaufs-API in meinem System (für andere Funktionen) und verwende sie weiter, um dies zu verhindern Die Seite lädt zwischen den Anfragen und damit die Musik auf jeder Seite.

Ich bin fest davon überzeugt, dass es am besten ist, die Tracks zu verwalten, die der Player zwischen den Views spielt. Wie zu erwarten, klickt ein Benutzer derzeit auf einen Link und erhält eine Liste mit Titeln. Die Tracks werden in den Player geladen und nacheinander abgespielt, einfach. Mit der fortwährend spielenden Musik muss ich jedoch sicherstellen, dass die richtige Playlist der Titel trotz des sich ändernden Inhalts auf der Seite in der richtigen Reihenfolge abgespielt wird und es sich nun um eine dynamische URL handelt.

Wenn der Benutzer jedoch zu einer anderen Seite navigiert, die Wiedergabe auf einem Titel in der neuen Wiedergabeliste drückt, muss ich in der Lage sein, diesen Eintrag in den Player zu laden und den Rest der Wiedergabeliste effektiv zu laden, während der Benutzer fortfährt navigieren.

Ich verwende Redis, um eine Liste der Track-IDs für eine Playlist zu speichern, um die Verzögerung zwischen den Tracks zu reduzieren. Als Ergebnis habe ich für jede Wiedergabeliste ein anderes Redis-Set. Ich habe auch meine Next und Previous Track API Aufrufe basierend auf dem aktuellen Track erstellt, so dass der nächste Track aus dem Redis Set in den Player geladen werden kann.

Wie bereits erwähnt, kann ich mich nicht entscheiden, welche Playlist gerade abgespielt wird, damit der Player weiß, von welchem ​​Redis aus er die Tracks aufrufen soll. Mein Denken hat mir ein paar verschiedene Ideen hinterlassen:

a) Benutzerdefinierte HTML5-Datenattribute - Ich könnte die aktuell wiedergegebene Playlist als Datenattribut auf dem Player festlegen und sie dann aktualisieren. Ich könnte dann auf dieses Attribut verweisen, wenn ich entscheide, von welchem ​​Redis ich den nächsten Track laden soll.

Alternativ könnte ich die aktuelle Wiedergabeliste und alle Spuren (und ihre Attribute) als JSON-Objekte in Datenattribute auf der Seite ablegen. Playlists könnten Tausende von Tracks lang sein, also lehne ich diese ab, weil der Quellcode schrecklich aussehen würde, geschweige denn die damit verbundenen Leistungsprobleme. Habe ich recht?

b) LocalStorage - Die Browserunterstützung ist begrenzt. Je mehr Unterstützung für diese Lösung, desto besser in diesem speziellen Fall. Trotzdem konnte ich die aktuelle Wiedergabeliste im Benutzerbrowser speichern. Dies hat mich dazu gebracht, mich zu fragen, ob es auch praktisch wäre, die JSON-Objekte der Tracks in LocalStorage zu speichern, um die zusätzlichen DB-Aufrufe zu verhindern.

c) In Session - Ich könnte die Sitzung aktualisieren, um eine Variable für die gerade abgespielte Playlist zu speichern.

d) Redis - Ich könnte meine Verwendung von Redis erweitern, um eine Zeichenfolge zu speichern, die auf den Namen der aktuellen Wiedergabeliste verweist. Ich könnte es dann zwischen jedem nächsten / vorherigen Track-Anruf überprüfen.

Durch das Schreiben dieser Frage habe ich bereits eine bessere Vorstellung davon, welchen Weg ich nehmen werde, aber wenn jemand einen Rat für dieses Szenario hat, dann würde ich gerne hören.

Danke.

UPDATE: Ich habe 95% einer Lösung implementiert, die Redis dafür verwendet. Ich habe ein paar Performance-Probleme, aber mit Seiten ~ 10 zu laden. Überhaupt nicht großartig.

Im Prinzip hat jeder Benutzer 2 Wiedergabelisten: Current und Armed. Jede Anfrage lädt die Track-IDs in die Redis Armed-Playlist und wenn die Play-Taste auf einem Track gedrückt wird, ist die Current Redis-Playlist abgelaufen und wird durch die Bewaffnete ersetzt.

Mit den Tasten Next und Previous rufen Sie einfach die ID des nächsten oder vorherigen Tracks in der aktuellen Playliste ab und laden die Musikquelle für den Player. Das Konzept funktioniert gut und ich bin zufrieden damit.

Wie bereits erwähnt, ist die Leistung zwischen den Seitenanforderungen jedoch gering und muss erheblich verbessert werden. Mein SQL ist optimiert, ich ziehe nur die erforderlichen Attribute heraus und ich habe SQL-Indizes wo nötig, also suche ich nach anderen Alternativen im Moment.

Optionen, die ich in Erwägung ziehe:

1. Füllen Sie die bewaffnete Wiedergabeliste nur aus, wenn auf der neuen Seite auf einen Track geklickt wird. Dies würde zusätzliche Verarbeitung sparen, wenn der Benutzer nicht wirklich auf eine der neuen Spuren hören möchte.

2. Indem Sie Redis verwenden und die Mager-Track-Objekte in den Redis-Playlists speichern und nicht nur die Track-ID, liegt die Performance-Verzögerung weitgehend zwischen den Seitenanforderungen und nicht in der tatsächlichen Wiedergabe von Titeln und Navigieren in einer Playlist.

3. Nutzen Sie eine Master-Redis-Playlist, die alle Anwendungen enthält, aus denen die aktuellen und die bewaffneten Playlists auswählen können. Dies könnte über eine stündliche Rake-Aufgabe aufrechterhalten werden und würde lange DB-Aufrufe bei Seitenanforderungen verhindern. Ich bin nur nervös, wie weit dies hinsichtlich der Speichernutzung auf dem Server und der Anzahl der Tracks in der DB skalieren würde.