Manga Reader - каталог и платформа для чтения манги

Обзор

Manga Reader - полноценная платформа для чтения манги, собранная по формальному техническому заданию: публичный каталог, открытый всем; личный кабинет для зарегистрированных читателей; отдельное рабочее место переводчика, который загружает новые главы; и админ-панель, управляющая каждым разделом сайта. Три интерфейса живут в одной кодовой базе и работают с одной базой PostgreSQL, но разделены по ролям - посетитель никогда не видит очередь модерации, а переводчик - управление пользователями.

Проблема

Сайт манги выглядит как каталог, а ведёт себя как рабочий процесс. Читателю нужны поиск, фильтры по тегам, избранное и комментарии. Переводчику нужно выкладывать главы, не дожидаясь разработчика. Админу нужно всё остальное: ничего из загруженного переводчиком не должно попадать в публичную часть без проверки, комментарии требуют модерации и фильтра мата, пользователям нужны роли и блокировки, а статические страницы должны редактироваться без правки кода. В большинстве реализаций решают только «читалку», а операционную половину - модерацию, роли, жалобы - оставляют на потом. Именно там сайт и ломается, когда приходят реальные пользователи.

Решение

Точка входа - каталог: полнотекстовый поиск по названиям и описаниям тайтлов, фильтр по тегам с множественным выбором и пагинация, и всё это на AJAX - смена фильтра перерисовывает сетку без перезагрузки страницы. На десктопе блок фильтров всегда развёрнут; на мобильных он свёрнут за кнопкой, чтобы не съедать экран. На странице тайтла - обложка, теги, описание, список глав по номерам, кнопка избранного, меняющая состояние на месте, и ветка комментариев с пагинацией. Чтение вынесено на отдельную страницу: страницы масштабируются под ширину экрана, а навигация между главами строится из номера текущей главы и наличия соседних.

У переводчика свой дашборд со счётчиками отправленных, одобренных и отклонённых глав и форма загрузки, куда глава приходит ZIP-архивом, который сервер распаковывает в директорию изображений тайтла. Форма предупреждает о совпадении номера главы - включая номера, уже стоящие в очереди на модерацию, - и каждая отправка сохраняется со статусом pending. Админ работает на другом конце того же конвейера: одобрить и опубликовать либо отклонить с текстовой причиной, которую переводчик увидит на своей странице «Мои главы». Вокруг этого - роли (user / translator / admin), блокировки, модерация комментариев с таблицей banned_words и антифлудом, очередь жалоб, управление тегами со статистикой избранного по тегам, глобальные переключатели комментариев, жалоб и регистрации и WYSIWYG-редактор статических страниц.

Возможности

• Каталог с AJAX-поиском по названию и описанию, фильтрами по тегам с множественным выбором и пагинацией - без перезагрузок
• Страницы тайтлов со списком глав, комментариями с пагинацией и мгновенным переключателем избранного
• Адаптивная читалка: страницы масштабируются под ширину экрана, ссылки «предыдущая / следующая глава» строятся по соседним главам
• Регистрация, авторизация и профиль, где пользователь меняет ник, тему и язык интерфейса
• Кабинет переводчика: статистика отправок, загрузка главы ZIP-архивом с проверкой дублирующегося номера, «Мои главы» со статусами и причинами отклонения
• Очередь модерации у админа: полный просмотр главы, одобрение или отклонение с сохранённой причиной, возвращаемой переводчику
• Управление ролями (user / translator / admin), блокировка и удаление: заблокированный не может войти, комментировать и загружать главы
• Модерация комментариев, фильтр banned_words и антифлуд-ограничение частоты отправки
• Очередь жалоб, управление тегами со статистикой избранного по тегам и глобальные настройки сайта
• Статические страницы, редактируемые через WYSIWYG-редактор TinyMCE, без деплоя
• Полностью двуязычный интерфейс: все подписи, ошибки и кнопки в языковых файлах, для мультиязычного контента - отдельные поля в БД

Процесс разработки

Стержень всей сборки - жизненный цикл главы: pending → approved | rejected. От него зависит остальное: счётчики в кабинете переводчика, очередь у админа, публичный список глав и причина отклонения, возвращающаяся автору загрузки. Правильно собранная машина состояний в начале позволила дальше наращивать панель раздел за разделом, не переделывая модель данных.

Больше всего внимания потребовал путь загрузки. Принять ZIP и распаковать его на сервере удобно переводчику, но для сервера это враждебный ввод: загрузки ограничены типами изображений (jpg, png, gif, webp), пишутся в директорию конкретного тайтла и сверяются с существующими номерами глав - включая находящиеся на модерации, иначе два переводчика займут одну и ту же главу. Админка намеренно сделана простой: нейтральные цвета, сортируемые и поисковые таблицы, пагинация везде и хлебные крошки - это рабочий инструмент, а не витрина.

Результаты

• Одна платформа обслуживает три роли из общей кодовой базы и базы данных
• Замкнутый цикл модерации: непроверенное не доходит до читателей, а каждое отклонение возвращается переводчику с причиной
• Массовая загрузка глав ZIP-архивом вместо файла за файлом
• Админ-панель, покрывающая весь сайт: тайтлы, главы, теги, пользователи, комментарии, жалобы, настройки и статические страницы
• Двуязычный интерфейс на языковых файлах: третий язык - это изменение данных, а не переписывание кода

Выводы

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