Архитектура музыкального проигрывателя с плейлистами, использующая Rails, Redis и HTML5

Question

Я разрабатываю приложение, которое имеет несколько музыкальных плейлистов, представление для каждого плейлиста и игрока.

Я использую в моей системе HTML5 History API (для других функций) и буду использовать его для предотвращения перезагрузки страниц между запросами и, следовательно, остановки музыки на каждой странице.

Я придерживаюсь наилучшего подхода к управлению треками, которые игрок будет играть между видами. В настоящее время, как и следовало ожидать, пользователь щелкает ссылку, получает список треков. Треки загружаются в плеер и воспроизводятся последовательно, просто. Однако при непрерывном воспроизведении музыки мне необходимо обеспечить правильный список воспроизведения треков, несмотря на изменение содержимого на странице, и теперь это динамический URL.

Однако, когда пользователь перейдет на другую страницу, нажмите кнопку воспроизведения на дорожке в новом списке воспроизведения, мне нужно будет загрузить этот элемент в плеер и эффективно загрузить оставшуюся часть списка воспроизведения, пока пользователь продолжает для навигации.

Я использую Redis для хранения списка идентификаторов дорожки для плейлиста, для ускорения ссылок на уменьшение отставания между дорожками. В результате у меня есть другой Redis для каждого плейлиста. Я также создал мои API-интерфейсы Next и Previous Track API на основе текущего воспроизведения трека, так что следующий трек из набора Redis может быть загружен в плеер.

Как уже упоминалось, хотя я просто не могу решить, как наилучшим образом указать, какой плейлист играет в данный момент, поэтому игрок знает, от чего Redis настроен на вызов дорожек. Мое мышление оставило меня с несколькими идеями:

a) Атрибуты пользовательских данных HTML5 - я мог бы установить воспроизводимый в данный момент плейлист как атрибут данных на проигрывателе и обновить его как и когда. Затем я мог бы ссылаться на этот атрибут при принятии решения о том, какой Redis установил для загрузки моего следующего трека.

В качестве альтернативы я мог бы сбросить текущий список воспроизведения и все треки (и их атрибуты) в виде объектов JSON в атрибуты данных на странице. Плейлисты могут быть длинными тысячами треков, хотя я увольняю это, потому что исходный код выглядел бы ужасно, не говоря уже о вероятных проблемах с производительностью. Я прав?

b) LocalStorage - Поддержка кросс-браузера ограничена. Чем больше поддержка этого решения, тем лучше в этом конкретном случае. Несмотря на это, я могу сохранить текущий плейлист в браузере пользователей. Это заставило меня задаться вопросом, было бы также целесообразно сохранять дорожки объектов JSON в LocalStorage, чтобы предотвратить дополнительные вызовы БД.

c) В сеансе - я мог обновить сеанс, чтобы сохранить переменную для воспроизводимого в данный момент плей-листа.

d) Redis - Я мог бы расширить свое использование Redis, чтобы сохранить строку, которая ссылается на имя текущего плейлиста. Затем я мог бы проверить его между каждым следующим/предыдущим треком.

Написав этот вопрос, у меня уже есть лучшее представление о том, какой маршрут я собираюсь взять, но если у кого-нибудь есть какие-либо советы по этому сценарию, то я бы хотел услышать, пожалуйста.

Спасибо.

UPDATE: Я воспользовался 95% решения, которое использует Redis для этого. У меня есть несколько проблем с производительностью, хотя на страницы приходится загружать ~ 10 секунд. Не очень.

По сути, каждый пользователь имеет 2 плейлистов: текущий и вооруженный. Каждый запрос загружает идентификатор дорожки в список воспроизведения Redis Armed, и если кнопка воспроизведения нажата на дорожке, список воспроизведения Current Redis истек и заменяется на Вооруженный.

Теперь мои кнопки Next и Previous просто выбирают идентификатор следующей или предыдущей дорожки в текущем списке воспроизведения и загружают в источник музыки для проигрывателя. Концепция отлично работает, и я доволен этим.

Однако, как упоминалось, производительность медленна между запросами страниц и требует значительного улучшения. Мой SQL оптимизирован, я только вытаскиваю необходимые атрибуты, и у меня есть SQL-индексы, где это необходимо, поэтому я ищу другие альтернативы на данный момент.

Варианты Я рассматриваю:

1. только заполнить Armed плейлист если дорожка щелкнул на новой странице. Это позволит сэкономить дополнительную обработку, если пользователь фактически не хочет прослушивать один из новых треков.

2. Использование Redis и сохранение объектов скудной дорожки в списках воспроизведения Redis, а не только идентификатор дорожки - отставание в производительности во многом зависит от запросов страницы, хотя и не в реальном воспроизведении дорожек и навигации по списку воспроизведения.

3. Используйте мастер-список воспроизведения Redis, который содержит все треки приложений, из которых могут выбрать текущий и вооруженный плейлисты. Это можно было бы сохранить с помощью ежечасной рейк-задачи и предотвратить длительные вызовы БД на запросы страниц. Я просто нервничаю, насколько это масштабируется с точки зрения использования памяти на сервере и количества треков в БД.

Answer 1

Я предлагаю c) В сеансе.
Сессионные данные можно получить с относительной легкостью как на стороне клиента, так и на стороне сервера.

Заполнение кэша Redis конкретными пользовательскими данными не очень хорошо масштабируется.

LocalStorage - правильный, это не удастся для большого% пользователей в текущую дату.

CustomData Атрибуты - просто беспорядочный, как отмечено.

Только мои 2 цента.

Answer 2

Если вам нужно смоделировать клиентское приложение, лучше всего иметь один источник состояния. Это одна из проблем, которую пытаются решить javascript MVC (V) C на стороне клиента. Я в основном знаком с backbone.js и ember.js, поэтому я могу поговорить с ними.

Backbone.js

Создать модель под названием Playlist и коллекцию под названием Playlists. Добавьте объект в свою коллекцию PlaylistscurrentPlaylist, в которой содержится текущий список воспроизведения. Затем определите вид с именем PlaylistView и определите на нем метод render.Связать события триггеров и привязок, чтобы при изменении currentPlaylist список воспроизведения автоматически перерисовывался. Для этого вам потребуется переместить рендеринг шаблона клиенту, но вы, вероятно, захотите это сделать, чтобы уменьшить количество обращений к серверу и уменьшить нагрузку на сервер, вызванную рендерингом.

ember.js

Создать контроллер (аналог коллекции магистральную) со свойством называется currentPlaylist и заполнить контроллер со всеми плейлистами, представленных в виде Ember.object с. Затем в шаблоне рулей плейлиста, включенном на страницу, вы можете привязываться к playlists.currentPlaylist, и шаблон будет повторно рендерироваться автоматически при изменении playlists.currentPlaylist.

Я, очевидно, оставляю подавляющее большинство деталей, но лучше всего оставить документацию по рамочной документации, примеры и учебные пособия.

отказ от ответственности: Я новичок в клиентских фреймворках, что является частью причины, по которой я не учитывал большинство деталей. Я ценю любого, кто может исправить меня, если я ошибаюсь.

Answer 3

Смешение сеанса и локального хранилища было бы хорошим подходом.

Но вместо того, чтобы загружать весь список воспроизведения, просто выберите X (например, 10) следующие треки и, возможно, также предыдущие X. Как только игрок добирается до последней песни, он выбирает следующие 10 песен, предыдущие можно рассчитать в клиенте.

Модель данных может быть просто хешем, где элемент [0] - текущая песня, а элементы [X] - следующие песни, а [-X] - предыдущие.

Сохранение информации о плейлисте на стороне клиента представляется мне разумным, но вы также можете использовать сеанс для ссылки на текущую песню и список воспроизведения, поэтому, когда пользователь возвращается или действительно перезагружает ваш сайт, вы все равно получаете песню, не делая вызов базы данных.