Django или готовая CMS: когда для проекта берут Python-стек

Вопрос «Django или CMS» почти никогда не является вопросом о языке. Он про то, насколько будущий проект похож на сайт — и насколько на приложение, у которого просто есть веб-интерфейс.

Что на самом деле выбирают

Готовая CMS — это набор заранее принятых решений: как устроен контент, как работает админка, как выглядят права доступа, как подключаются расширения. Пока проект укладывается в эти решения, вы получаете огромную фору: половина работы уже сделана.

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

Где CMS выигрывает уверенно

• Контентные сайты. Корпоративный сайт, медиапроект, каталог, лендинги — всё это CMS делает из коробки, включая редактуру, черновики и медиабиблиотеку.
• Типовая коммерция. Товары, корзина, заказы, скидки, интеграции с платёжными системами и службами доставки уже написаны и проверены на тысячах магазинов.
• Проекты, которые ведёт не разработчик. Контент-менеджер, маркетолог и редактор получают интерфейс, к которому привыкли, без вложений в разработку админки.
• Ограниченный бюджет и жёсткий срок. Запустить за две недели на готовой платформе реально, с нуля на фреймворке — обычно нет.

Где CMS начинает сопротивляться

Признак один и тот же во всех платформах: вы всё чаще решаете задачу не «с помощью» системы, а «вопреки» ей.

• Модель данных не ложится на сущности CMS. Когда заказ — это не заказ, а договор с графиком платежей, набором согласований и версиями, попытка уложить его в товарную карточку заканчивается плохо.
• Бизнес-процесс сложнее статуса. Расчёты, конечные автоматы, права, зависящие от этапа, — всё это дописывается поверх, и каждое обновление платформы становится риском.
• Основная ценность — не контент. Если 80% кода это расчёты, интеграции и обработка данных, то CMS обслуживает оставшиеся 20%, а мешает всем остальным.
• Нужен полный контроль над схемой и запросами. Сложные агрегации на миллионах строк неудобно писать через абстракции, рассчитанные на карточку товара.

Что даёт Django на этих задачах

Django популярен не потому, что «Python модный», а потому что он закрывает скучную часть работы, не навязывая предметную модель:

• ORM с миграциями. Схема живёт в коде, изменения версионируются и накатываются предсказуемо.
• Админка из коробки. Не замена пользовательской CMS, но полноценный внутренний инструмент, который появляется почти бесплатно.
• Формы и валидация. Один из самых недооценённых компонентов: сложные формы с зависимой валидацией пишутся быстро и читаемо.
• Безопасность по умолчанию. Экранирование в шаблонах, защита от CSRF, параметризованные запросы — включены, а не подключаются вручную.
• Соседство с Python-экосистемой. Если проекту нужны обработка данных, отчёты или интеграция с ML-моделями, они оказываются в том же процессе, а не за границей сервиса.

Цена входа, о которой стоит помнить

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

Поэтому честный вопрос при выборе звучит так: сколько из возможностей CMS проекту действительно нужно? Если больше половины — берите CMS. Если вы всё равно будете переписывать её ключевые части, экономия окажется мнимой.

Гибрид, который часто оказывается верным ответом

Между «всё в CMS» и «всё с нуля» есть рабочая середина: контент остаётся в системе, которая с ним хорошо справляется, а специфическая логика выносится в отдельное приложение.

Практически это выглядит так: сайт и редакторская работа — на CMS; расчёты, личный кабинет, обмен с внешними системами — отдельный сервис на Django; между ними REST-контракт. Такое разделение позволяет обновлять CMS без страха и развивать бизнес-логику, не оглядываясь на структуру инфоблоков или нод.

Практический способ выбрать

Полезное упражнение — описать десять главных пользовательских сценариев проекта и напротив каждого честно отметить: этот сценарий CMS закрывает сама, закрывает с доработкой или не закрывает вовсе. Если во втором и третьем столбце оказалось большинство, ответ на вопрос из заголовка вы уже получили.