Медиа-журнал с нуля: стек, сроки и решения (кейс Сансара)

Меня зовут Чимитдоржи Дарижапов. В этом материале я разбираю на собственном опыте, как устроен проект «Сансара» — онлайн медиа-журнал, культурно-философское издание, для которого я собрал и сайт, и собственную редакционную систему управления. Сразу оговорюсь: речь пойдёт про инженерную и продуктовую часть — как сделать так, чтобы редакция публиковала материалы сама, чтобы длинные тексты с фотографиями читались приятно, и чтобы всё это жило на своём сервере, а не в чужом личном кабинете. О содержании самого журнала здесь почти ничего не будет — это отдельная история.

Что было нужно

Запрос звучал обманчиво просто: «нужен сайт для журнала». Но за этой фразой стоит целый набор требований, которые быстро выводят проект за пределы возможностей типового конструктора. Давайте разложу, что на самом деле требовалось.

Во-первых, это должно было быть именно издание, а не персональный блог. Разница принципиальная. Блог — это лента заметок одного автора. Издание — это структура: рубрики, разделы, редакционный процесс, где материал проходит путь от черновика до публикации. Значит, нужен нормальный рубрикатор, по которому можно раскладывать материалы, и по которому читатель ориентируется на сайте.

Во-вторых, редакция должна вести материалы сама, без моего участия в роли «человека, который вставляет тексты». Это ключевое требование. Если каждую публикацию приходится отдавать разработчику — издание не живёт, оно стоит. Значит, нужна удобная админка, в которой нетехнический человек спокойно создаёт статью, добавляет фотографии, выбирает рубрику и нажимает «опубликовать».

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

В-четвёртых, SEO. Медиаконтент живёт за счёт поиска: люди приходят на конкретные материалы из поисковых систем. Значит, каждая статья должна корректно отдаваться поисковику — с правильными заголовками, описаниями, быстрой загрузкой и чистой структурой страницы.

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

Почему не Тильда и не готовая CMS

Логичный вопрос: зачем городить свою систему, если есть Тильда и другие конструкторы, а также готовые коробочные CMS? Я честно взвешивал этот путь, и вот почему в итоге пошёл в кастомную разработку.

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

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

Контроль над SEO и скоростью. На конструкторе ты управляешь SEO ровно настолько, насколько это разрешил конструктор. В своём коде я контролирую всё: разметку, метаданные, скорость отдачи страниц, структуру URL. Для медиа, которое живёт с поиска, это не мелочь, а фундамент.

Отсутствие абонплаты платформе. Конструктор — это аренда навсегда. Пока платишь — работает. Своё решение на своём VPS — это разовая сборка и предсказуемая стоимость хостинга, без ежемесячной привязки к чужому тарифу.

Что я сделал

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

Первая часть — сайт-витрина журнала. Это то, что видит читатель: главная страница, страницы рубрик, страницы отдельных материалов. Здесь всё заточено под чтение и под поиск: быстрая загрузка, аккуратная типографика, удобная навигация по разделам, корректная SEO-разметка на каждой странице.

Вторая часть — отдельная админка для редакции. Это внутренний инструмент, закрытая от читателей панель, в которой редакция создаёт и редактирует материалы, загружает фотографии, собирает галереи, раскладывает статьи по рубрикам и управляет публикацией. Админка сознательно сделана отдельным приложением — ниже объясню, почему это правильно.

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

Стек и админка

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

Зачем Next.js для витрины

Для публичной части журнала я выбрал Next.js по двум главным причинам — SEO и скорость. Медиа-издание получает читателей из поиска, а значит, страницы материалов должны отдаваться поисковику уже готовыми, с полным содержимым и правильными метаданными. Next.js умеет рендерить страницы на сервере, и это даёт именно то, что нужно: поисковик видит статью целиком, а читатель получает быстро загружающуюся страницу. Для длинных материалов скорость особенно важна — большой текст с фотографиями не должен заставлять читателя ждать.

Зачем Prisma для базы

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

Почему админка — отдельное приложение на Vite + React

Это, пожалуй, самое интересное архитектурное решение. Админку я сделал не частью сайта, а отдельным приложением на Vite + React. Причин несколько.

Админка и витрина решают разные задачи. Витрина оптимизирована под чтение и поиск, ей важен серверный рендер и SEO. Админка — это интерактивный рабочий инструмент, панель, где важна скорость отклика интерфейса, а не индексация поисковиком (её как раз индексировать не нужно). Vite даёт быструю разработку и лёгкое, отзывчивое приложение — идеально для внутреннего инструмента.

Разделение упрощает жизнь. Публичный сайт и внутреннюю панель можно развивать и обновлять независимо. Проблема в одном не роняет другое. И с точки зрения безопасности редакционная панель отделена от публичной части — это чище и надёжнее.

Что было сложно

Проект не был прогулкой, и честно перечислю, где пришлось повозиться.

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

Удобство админки для нетехнической редакции. Это была, возможно, главная продуктовая сложность. Легко сделать панель, удобную для программиста. Трудно сделать панель, в которой уверенно работает человек, далёкий от техники. Каждое поле, каждая кнопка, каждый шаг создания материала должны быть понятны без инструкции. Загрузка фотографий, сборка галереи, выбор рубрики, сохранение черновика и публикация — всё это должно ощущаться естественно. Я много раз мысленно ставил себя на место редактора и упрощал то, что казалось мне очевидным, но на деле таковым не было.

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

Производительность. Длинные страницы с большим количеством изображений — это вызов для скорости. Нужно было следить, чтобы материалы грузились быстро несмотря на объём, чтобы фотографии не тормозили открытие страницы, чтобы читатель не ждал. Баланс между качеством картинок и скоростью отдачи — постоянная инженерная работа.

Что получилось

В результате «Сансара» — это работающее онлайн-издание, которое живёт своей жизнью. Редакция публикует материалы сама, через собственную админку, без обращения к разработчику на каждую статью. Материалы раскладываются по рубрикам, оформляются с фотогалереями, читаются как настоящие журнальные лонгриды.

Издание работает на своём VPS (Timeweb) — в продакшене, на собственном сервере, без привязки к какой-либо платформе-конструктору и без абонентской платы за право публиковать. Журнал принадлежит редакции целиком: свой код, своя база, свой хостинг.

Технически получилась чистая и понятная конструкция: публичная витрина на Next.js, заточенная под чтение и поиск; редакционная админка на Vite + React, заточенная под удобство работы; общая база под управлением Prisma. Всё это я собрал и запустил один — от архитектуры до деплоя.

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

Что бы сделал иначе

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

Раньше и жёстче зафиксировал бы схему данных. Prisma сильно помогла, но структуру статей, рубрик и медиа стоило продумать ещё детальнее на самом старте — чем яснее модель данных в начале, тем меньше правок потом.

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

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

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

Частые вопросы

Чем это лучше готовой платформы для блогов? Свой журнал даёт полный контроль над вёрсткой, рубрикатором, скоростью и SEO, и не привязывает к абонплате и правилам чужой платформы. Для разового блога это избыточно, а для издания, которое планируют развивать, — оправдано.

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

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

Коротко о главном

Полноценное онлайн-издание — это не «сайт на конструкторе», а связка из читательской витрины и редакционного инструмента. Витрина отвечает за чтение, скорость и поиск; админка — за то, чтобы редакция жила самостоятельно. Разделение этих двух миров, продуманная схема данных и свой сервер дают изданию главное — независимость и контроль.

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

А если вам нужен медиапортал или издание с удобной админкой, в котором редакция публикует материалы сама — напишите мне, обсудим вашу задачу спокойно и по делу.