Архитектура музыкального плеера с плейлистами, используя Rails, Redis и HTML5
Я разрабатываю приложение, которое имеет несколько музыкальных плейлистов, представление для каждого плейлиста и плеер.
Я уже использую HTML5 History API в своей системе (для другой функциональности) и буду использовать его дальше, чтобы предотвратить перезагрузку страницы между запросами и, следовательно, остановку музыки на каждой странице.
Однако я застрял в вопросе о том, как лучше всего управлять треками, которые плеер будет проигрывать между просмотрами. В настоящее время, как и следовало ожидать, пользователь нажимает на ссылку, получает список треков. Треки загружаются в плеер и проигрываются последовательно, все просто. Однако при постоянно играющей музыке мне нужно обеспечить воспроизведение правильного списка треков по порядку, несмотря на меняющееся содержимое страницы и ее динамический URL.
Однако, когда пользователь переходит на другую страницу, нажимает воспроизведение трека в новом списке воспроизведения, мне нужно иметь возможность загрузить этот элемент в плеер и эффективно загрузить остальную часть списка воспроизведения, пока пользователь продолжает перемещаться.
Я использую Redis для хранения списка идентификаторов треков для плейлиста, чтобы ускорить обращение к нему и уменьшить задержку между треками. В результате у меня есть отдельный набор Redis для каждого плейлиста. Я также построил свои вызовы API Next и Previous Track на основе текущего воспроизводимого трека, чтобы следующий трек из набора Redis мог быть загружен в плеер.
Однако, как уже упоминалось, я никак не могу решить, как лучше ссылаться на текущий список воспроизведения, чтобы плеер знал, из какого набора Redis вызывать треки. Мои размышления привели меня к нескольким различным идеям:
a) Пользовательские атрибуты данных HTML5 - я мог бы установить текущий список воспроизведения как атрибут данных на плеере и обновлять его по мере необходимости. Затем я мог бы ссылаться на этот атрибут, когда решаю, из какого набора Redis загрузить следующий трек.
В качестве альтернативы я мог бы сбрасывать текущий плейлист и все треки (и их атрибуты) в виде JSON-объектов в data-атрибуты на странице. Однако плейлисты могут состоять из тысяч треков, поэтому я отбрасываю этот вариант, поскольку исходный код будет выглядеть ужасно, не говоря уже о вероятных проблемах с производительностью. Я прав?
b) LocalStorage - Кроссбраузерная поддержка ограничена. Чем больше поддержка этого решения, тем лучше в данном конкретном случае. Несмотря на это, я смог сохранить текущий список воспроизведения в браузере пользователя. Это заставило меня задуматься о том, не будет ли практичным также сохранять JSON-объекты треков в LocalStorage, чтобы избежать дополнительных обращений к БД.
c) In Session - я мог бы обновить сессию, чтобы сохранить переменную для текущего воспроизводимого списка воспроизведения.
d) Redis - Я мог бы расширить использование Redis для сохранения строки, ссылающейся на название текущего списка воспроизведения. Затем я мог бы проверять ее между каждым вызовом следующего/предыдущего трека.
Написав этот вопрос, я уже лучше представляю, какой путь я собираюсь выбрать, но если у кого-нибудь есть советы по этому сценарию, я буду рад их услышать.
Спасибо.
UPDATE: Я реализовал 95% решения, которое использует Redis для этого. Однако у меня есть некоторые проблемы с производительностью: загрузка страниц занимает ~10 секунд. Не очень хорошо.
По сути, у каждого пользователя есть 2 плейлиста: Текущий и Вооруженный. Каждый запрос загружает идентификаторы треков в список Redis Armed, и если на треке нажата кнопка воспроизведения, текущий список Redis теряет силу и заменяется на список Armed.
Мои кнопки Next и Previous затем просто получают ID следующего или предыдущего трека в текущем списке воспроизведения и загружают источник музыки для плеера. Концепция работает хорошо, и я доволен ею.
Однако, как уже говорилось, производительность медленная между запросами страницы и требует значительного улучшения. Мой SQL оптимизирован, я извлекаю только необходимые атрибуты, и у меня есть SQL-индексы там, где это необходимо, поэтому в данный момент я ищу другие альтернативы.
Варианты, которые я рассматриваю:
Только заполнение списка воспроизведения Armed, если трек нажимается на новой странице. Это сэкономит дополнительную обработку, если пользователь на самом деле не хочет слушать один из новых треков.
Более широкое использование Redis и хранение объектов lean треков в плейлистах Redis вместо простого идентификатора трека - отставание в производительности происходит в основном между запросами страницы, а не в фактическом воспроизведении треков и навигации по плейлисту.
Используйте главный список воспроизведения Redis, содержащий все треки приложений, из которых могут выбирать текущий и вооруженный списки воспроизведения. Это можно поддерживать с помощью ежечасной задачи rake и предотвратить длительные обращения к БД при запросах страниц. Я просто нервничаю, насколько это будет масштабироваться в плане использования памяти на сервере и количества дорожек в БД.