СМИ с точки зрения пользователя – это канал, по которому он получает актуальную информацию в удобном виде.
СМИ с точки зрения разработчика – это интуитивно понятный для пользователя и хорошо оптимизированный сервис с данными.
Проект сайта для известного новостного ресурса получился одинакого приятным со всех точек зрения. Подробнее о том, как шла работа “изнутри” – в нашей статье.
В начале работы мы провели анализ задач:
- настройка понятного и удобного редакторского поля для авторов статей
- предоставление статей пользователю в унифицированном виде
- подключение к статьям метаданных, а также колонки с релевантными материалами
- генерация уникальных страниц разделов и запросов по настраиваемым шаблонам
Пользователями проекта являются авторы статей и посетители сайта. Поэтому структура сайта должна быть одинаково удобной и для первых, и для вторых – с интуитивной навигацией без сложных фильтров и личных кабинетов.
В качестве инструмента для создания статей мы использовали готовый продукт, который предварительно настроили под наш проект. Это позволило дать людям, которые будут писать материалы для издания, простое и и хорошо оптимизированное поле для работы и коммуникации.
Далее, для написания основного связующего Rest Api бэкенда, мы использовали Django с надстройкой Rest Framework, подключенными базами данных MongoDB и Redis, а также с воркером отложенных задач celery. Это помогло стандартизировать запросы к базе данных, сделать ее структуру более четкой, а выполнение запросов – более слаженным.
Архитектурное решение первоначально вызвало внутри команды много дискуссий. Нам важно было понять, как лучше всего доставить информацию (новостные статьи) до пользователя. Выбирали из двух вариантов – использовать готовый модуль расширения поля для авторов или написать свой бэкенд, который будет соединять имеющийся инструмент с фронтендом, т.е. с тем, что увидит пользователь.
В итоге, после многочисленных тестов мы решили вынести бэкенд в отдельную “сущность” (а-ля облачный сервис), которая будет принимать, обрабатывать и хранить статьи от авторов.
Первую продакшн версию сайта мы сделали примерно за 2 месяца, а потом продолжили работу – добавили по просьбе клиента новый функционал и оптимизировали работу всех структурных элементов.
Проект продемонстрировал, что для обработки структурных данных – таких, как новостные статьи – очень эффективно использование документо-ориентированной базы данных MongoDB. А также, что хорошо оптимизированные облачные сервисы могут стать решением многочисленных проблем. В нашем проекте мы использовали их для преодоления трудностей интеграции с готовым продуктом (инструментом для авторов) и сохранения одинаковых состояний для всех поступающих данных.
Спасибо за внимание, будем рады пообщаться с вами в комментариях!
А цель статьи? Ну выбрали, ну написали...
Расскажите лучше, как в монге сделать джоин (хорошо, агрегацию) между таблицами с парой млн записей... чтобы база не делала пару млн операций при этом:)
У самого монга в проде, но это далеко не идеальная БД. И какие то базовый вещи реляционной БД тут делаются совсем не тривиально.
Интересно было услышать ваше мнение, спасибо! Будем иметь в виду, что есть запрос на такого рода статьи)
А целью всего нашего блога на этой платформе является, в первую очередь, общение и обмен опытом. Мы знаем, как это важно, особенно для начинающих разработчиков!