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

Question

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо.

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

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

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

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

Опции, которые я рассматриваю:

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

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

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

Answer 1

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

Backbone.js

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

Ember.js

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

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

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

Answer 2

Хорошим подходом будет сочетание сессии и локального хранилища.

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

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

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

Answer 3

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

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

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

Атрибуты CustomData - просто грязно, как отмечалось.

Просто мои 2 цента.