прислать материал
AIN.UA » Бизнес, Колонки, МненияПроблема дистрибуции и хранения медийного контента — опыт и лайфхаки Genesis Media
 

Проблема дистрибуции и хранения медийного контента — опыт и лайфхаки Genesis Media

1403 3

Вячеслав Одиноков, глава технической разработки новостных проектов в Genesis Media Emerging Markets (GMEM), рассказал о многоканальном подходе в дистрибуции контента и о том, как в компании решали проблему хранения медийного контента на проектах.

Наши проекты представлены на множестве различных платформ, таких как AMP, Instant Articles, FreeBasics и др. Также мы плотно работаем с довольно экзотическими браузерами, например Opera Mini, который используется в Африке для экономии трафика. В нашей парадигме мультиплатформенности это еще одна полноценная платформа дистрибуции контента, со своими вызовами.

Вот неполный список проблем, которые нам удалось решить с помощью описанного ниже подхода:

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

Google, Facebook и другие предлагают собственные платформы дистрибуции, например AMP, Instant Articles. Они позволяют сделать страницы сайта доступнее, а опыт работы с ними приятнее. Это особенно важно на развивающихся рынках Африки и Азии, где мы работаем. Подход, который мы используем для хранения наших статей, позволяет быстро запускаться на новых платформах и своевременно реагировать на изменения на тех платформах, где мы уже работаем.

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

Особенности работы с платформами

Страницы AMP доступны только мобильным пользователям. На них можно попасть из поиска Google или с сайта Google Plus. Некоторые другие сайты также могут использовать версию AMP (например, Twitter и «ВКонтакте»).

Такие страницы откроются прямо на сайте поиска Google или на Google Plus без перезагрузки страницы, а все ресурсы на странице загрузятся асинхронно. Страницы AMP хранятся на серверах Google, поэтому загружаются быстро.

Иконка молнии в поиске Google означает доступность AMP. Такая страница откроется прямо на сайте поиска.

Подобным образом работает и Instant Articles. Страницы Instant Articles доступны только пользователям приложения Facebook. Хранятся страницы на серверах Facebook и открываются прямо внутри приложения.

 

Иконка молнии в приложении Facebook означает доступность Instant Article. Такая страница откроется прямо в приложении.

Для каждой названной платформы нужно иметь отдельные варианты целевых страниц. Разные варианты – это разные разметки. Кроме того, у каждой платформы есть свои ограничения и особенности.

Ниже –  простые примеры разметки.

Создание и хранение статей

Прежде наша редакция использовала один из текстовых HTML-редакторов типа TinyMCE. Статьи хранились в базе данных в разметке HTML. Это было неудобно и небезопасно.

HTML – это одна из частных реализаций разметки. Не следовало привязываться к ней.

Пересмотрев подход к хранению статей, мы решили использовать формат JSON. Теперь храним абстрактное представление статьи, из которого можно собрать любую разметку.

Пример статьи в формате JSON.

Для редакции техническая команда разработала удобную админку на ReactJS, в которой теперь создаются все материалы для сайтов. В админке используется редактор DraftJS.

Часть страницы с текстовым редактором DraftJS, в котором работает редакция.

DraftJS использует свой формат для хранения статей и работы с ними. Мы преобразуем этот формат в наш JSON, который и храним в базе данных. У нас есть специальный компонент с нужными сервисами, который отвечает за построение разных разметок.

Что мы получили в итоге?

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

Если что-то изменится в требованиях платформ, мы сможем быстро отреагировать – достаточно подправить сервис для генерирования конкретной разметки.

Относительно быстро и легко мы можем зайти и на новую платформу. Более того, довольно легко сделать особую версию страницы для отдельной группы пользователей. К примеру, для пользователей с браузером Opera Mini на наших африканских сайтах отдельная разметка. В ней видео-ролики, например, заменены на ссылки, чтобы страницы загружались быстрее. Для пользователей же с современными браузерами мы используем тег <picture> и другие интересные возможности.

Редакции запрещено вставлять что попало в статью. Больше нет доступа непосредственно к разметке. Оговариваем список разрешенных блоков для вставки (напр, блоки Twitter, Instagram, Facebook и мн. др.). Это важно, поскольку только так можно ручаться за то, что страница статьи отобразится правильно, а пользователь не получит вредоносный код (бывало и такое).

С использованием JSON для хранения статей появилась возможность использовать JSON Schemа для валидации.

В таком виде мы храним статьи уже около 2 лет, и у нас нет потребности что-либо менять. Описанный подход себя оправдал.

Выводы

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

Важно отделить контент от представления (разметки) – это позволит создать модель для хранения контента, которая будет удовлетворять потребностям бизнеса. Если вы решите работать с новой платформой, то технически будете готовы к этому.

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

Автор: Вячеслав Одиноков, глава технической разработки новостных проектов в GMEM

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

4 комментария

по хронологии
по рейтингу сначала новые по хронологии
Illia Ratkevych

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

Viacheslav Odynokov

Спасибо за Ваш интерес к теме и за интересные вопросы.
- у нас есть история изменений по каждой статье. Мы логируем все действия со всеми сущностями (статьи, рубрики, меню и прочее). В каждой записи лога содержатся сведения о том, как было и как стало.
- Не планируем. Однажды на глаза попался проект с открытым исходным кодом на GitHub'е, который делал примерно то же самое: преобразовывал формат DraftJS в JSON. Я хотел поделиться с Вами ссылкой, но так и не смог его найти.

😮😮😮😮😮😮😮😮😮😮😮
😜😜 http://goo.gl/bSdizJ 😜😜
🤔🤔🤔🤔🤔🤔🤔🤔🤔🤔

German Malinovsky

Тема интересная, но на мой взгляд много подводных камней.

Не совсем понятно как вы с такой простой структурой JSON решаете ситуации когда более сложная верстка текста, чем просто сверху вниз расположение блоков идет (Параграф -> Фото -> Параграф -> Видео ФБ -> Твит), когда вид и расположение блоков в "контейнере" статьи производное (обтекание, сужение текста, междустрочного интервала, гарнитура шрифта, разбивка на колонки текста) и нужно указывать адаптивность блоков. То есть то что в обычном редакторе TinyMCE делается инлайновыми стилями или плагином виджетов. Вот есть популярное решение для редакций Setka Editor и перенести хранение структуры блоков на JSON с первого взгляда кажется тяжелой задачей.

И еще. Думали ли вы о стратегии решения проблемы, когда вы сделали на блоках статью в 2016 году, а в 2019 у вас генерируемый JSON для некоторых или многих блоков поменялся (например, для Youtube вставок у блока поменялись атрибуты) и парсер уже будет статью за 2016 считать битой без этих знаний.

Поиск

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: