С каждым новым проектом в разработке и разработчикам, и порой заказчикам, приходится делать такой выбор. При этом часто можно услышать:
— CMS только для несложных / шаблонных проектов;
— если нужна нестандартная логика — поможет только фреймворк.
Посмотрим, так ли это, всегда ли это так, а заодно рассмотрим несколько, возможно, странных, но настоящих мифов и возражений заказчиков.
CMS — Content Management System, система управления контентом. Популярные CMS — это Wordpress, Drupal, ModX, Joomla и, конечно же, 1С-Битрикс. В CMS предполагается наличие административного интерфейса и настроек.
Фреймворк (framework) — это набор инструментов, библиотек и способов написания кода, который обычно не предполагает уже существующих настроек и конфигураций, а предполагает их программирование. Популярные фреймворки веб-разработки — это, например, Laravel, Symfony, Django, Yii, Ruby on Rails, Next.js.
CMS vs Фреймворк
С определениями определились, можно перейти к собственно выбору. Тут нужно отметить, что любая инженерная работа состоит из компромиссов. Мы платим тепловыделением за производительность, сроком службы за ёмкость, массой за функциональность, деньгами за качество. Мы знаем о теореме CAP и треугольнике «быстро-хорошо-дёшево». А выбор CMS, выбор фреймворка — это тоже компромиссы.
CMS
Вот так выглядит страница админки CMS Drupal сразу (ну, почти сразу) после установки:
Нетрудно заметить, что админка полна неких инструментов. Скорее всего, некоторые из них нам не нужны, но об этом позже. В первую очередь там уже есть инструменты для решения повседневных задач: создания и управления материалами, загрузки картинок, работы с wysiwyg-редакторами, настройки чпу и редиректов, различных лент, списков, блоков и слайдеров, заполнения метатегов и микроразметки. Все эти инструменты и настройки способны значительно, порой даже в разы ускорить создание нашего веб-проекта. Так чем мы за это платим? Мы платим:
— Конечно, гибкостью разработки: чем более универсальный и функциональный инструмент у нас в руках, тем больше он тянет за собой правил и ограничений. Как его настраивать, как им пользоваться, как под него верстать и конечно как писать код.
— «Неидеальным» устройством инструментов: когда их делали, нас не спрашивали, удобно ли нам. Поэтому сделано так, как удобно кому-то другому. Если нам какая-то из функций не нравится, придется или отключить, или приспособиться.
— Неким моментом борьбы: когда нам понадобится создать что-то необычное, для чего готовых инструментов или «полуфабрикатов» нет, нам возможно придется «бороться» с системой, то есть с её правилами и ограничениями.
Фреймворк
Фреймворк — это просто набор библиотек и инструментов для кодинга. Разумеется, у него тоже есть некоторое количество правил и ограничений: паттерны разработки, существующие библиотеки для аутентификации, поддерживаемые шаблонизаторы, способы написания тестов. Но этих правил гораздо меньше, и почти любое из них можно переопределить. То есть мы имеем максимальную гибкость и контроль разработки. Чем мы за это платим? Вот так, например, выглядит панель управления в Laravel сразу (ну, почти) после установки:
За гибкость и контроль здесь мы платим деньгами и временем. То есть, те из инструментов и настроек, которые нам нужны, придется разработать самим.
Хорошая новость тут в том, что нам нужно гораздо меньше инструментов, чем есть в CMS, и они не обязаны быть такими же универсальными. Плохая новость в том, что делать их всё равно дольше и дороже, чем взять то, что есть в CMS.
(Не)легкий выбор
И вот мы подходим к необходимости согласиться на тот или иной компромисс. Что для нас важнее? Готовые функции и скорость их использования, или гибкость и удобство кодинга?
Если отбросить нетехнические аспекты выбора (маркетинг, доступность кадров, ретроградность Меркурия), технический выбор за CMS или фреймворк мы делаем исходя из сочетания двух параметров:
- Доля контента в проекте от 100% до 0%. Чем больше контента (новости, статьи, блочные лонгриды, красивые лендинги, товары) — тем больше функций системы управления контентом нам потребуется.
- Доля необычных задач в проекте от 100% до 0%. Под необычными задачами имеется в виду, что их придётся написать, как ни крути. Хоть под CMS, хоть под фреймворк. Соответственно, чем больше ручного кода, тем больше нам придётся бороться с CMS вместо того, чтобы ей наслаждаться. Предположительно.
То есть, чем больше доля контента и меньше необычного кода, тем больше у нас гармония с CMS. И наоборот, чем меньше нам нужно работать с контентом, и больше решить нестандартных задач, тем меньше нам CMS нужна (и тем больше она мешает, предположительно).
Остается понять, в каких значениях этих двух параметров нам склоняться в сторону того или иного решения. И тут многое зависит от гибкости той CMS которой мы умеем пользоваться. Мы чаще всего работаем с Drupal. Это очень гибкая CMS, поэтому где-то до 70% доли кастомного кода и нестандартных задач я о фреймворках не вспоминаю вообще и рекомендую заказчикам брать CMS. А в плане доли работы с контентом, 40% и выше контентных задач на проекте — опять же, CMS будет наше всё.
Несмотря на то, что сам я фреймворки тоже люблю, люблю писать руками код, применять и сочинять паттерны, по клавиатуре пальцами стучать…
Кейсы
Попробую проиллюстрировать эту слегка абстрактную идею. Рассмотрим коротко несколько проектов, ссылки давать не буду, чтобы не отвлекаться.
Санкт-Петербургская консерватория
Сайт много лет работает на Drupal. Это контентный сайт, основное назначение которого — размещени информации об учебном заведении и процессе, об афишах, экзаменах, педсоставе. Поэтому использование CMS вполне естественно. Нестандартные решения там есть, но они минимальны, их вполне логично запрограммировать модулем для CMS. 100% контента и 1% кастомного кода. Выбор в пользу CMS очевиден.
Магазин известного бренда обуви
который, конечно же, нельзя называть по условиям договора
В целом интернет-магазины — это CMS. Интеграция с поисковым сервером, товары, атрибуты, фасеты, оплата и оформление — все это в CMS есть. Но здесь потребовалась значительная ручная работа для поддержки:
— нестандартного порядка оформления и сопровождения заказа;
— двузначного числа способов доставки, которые меняются от различных условий;
— синхронизации со складами через нестандартные протоколы;
— вмешательства в поисковую индексацию, чтобы отдельно индексировать атрибуты товаров, но не поломать фасеты.
Это приличное количество кода, но, недостаточное, чтобы отказаться от готовых решений CMS для e-commerce. 70–80% работы с контентом, 30–40% нестандартных задач. CMS.
Система дистанционного обучения (СДО, LMS)
В СДО можно сделать много всякого интересного: геймификацию, личные кабинеты, учебные планы и календари, группы пользователей, конструкторы квизов, торговлю курсами. Но всё это завязывается на главное — курсы и уроки, то есть контент. При этом кода ручного много, но почти для всего вышеперечисленного в CMS находятся инструменты и модули. Доля контента 70%, нестандартного кода 50%. Дважды реализовывали СДО с нуля под ключ на CMS, в третий раз поступили бы так же.
Многостраничный сайт, чисто контентная история
Представьте себе сайт (многостраничник для малого/среднего бизнеса), где редакторы без особого труда создают контентные страницы из различных блоков как в конструкторе. Лэндинги с описанием услуг, галереи работ, страницы вакансий и событий. Баннеры такие, баннеры сякие, коллауты, тайлы, тексты с картинками. По сути, для такого CMS и созданы.
Но есть нюанс: этот контент необходимо автоматически распределять между полусотней дочерних сайтов по сложной, контролируемой редакторами системе подписок (комбинации категорий, ручные подписки и отписки и т.д.) Казалось бы, куда необычнее — даёшь фреймворк! Но нет, CMS неплохо справилась и с этим. Доля контентной логики здесь — около 100%, поэтому было бы весьма тяжело отказаться от всех удобств, предоставляемых системой управления контентом. И не надо. Доля сложного кода — около 50%.
Платформа для запуска телеграм-ботов
Нужно запустить произвольных ботов, дать им очереди для обработки сообщений, статистику, API для команд и общения с пользователями. Контента как такового нет: то что мы можем отправить в телеграм, умещается в один редактор плюс прикрепленное медиа. Работы с контентом ~5–10%, необходимости в CMS нет, как и практической пользы от нее. Фреймворк 100%.
Даже если нам понадобится завести отдельный блог на платформе, это можно сделать с помощью одной из готовых библиотек под фреймворк (например Canvas под Laravel). Возможно будет не так круто, как блог на CMS, но оно и не нужно.
Сервис управления графиками работы персонала
Ключевая фича сервиса — связи между рабочими местами, должностями и сотрудниками, правила распорядка и асинхронные вычисления для автоматического построения графиков. Необходимости публиковать контент — нет, 0%. Возможные красочные лендинги для системы можно реализовать вообще отдельно другими средствами. А уровень сложного кода — 100%. CMS тут ни к чему, берём фреймворк.
Мифы
Напоследок рассмотрим несколько мифов, возражений и заявлений, которые регулярно можно встретить в процессе выбора.
«Для нестандартной логики подойдет только фреймворк» На эту тему мы уже порассуждали выше. Это далеко не всегда так.
Во-первых, многие «нестандартные» вещи (очереди, сложный импорт, REST API, батчинг) прекрасно реализуются в современных CMS, не хуже, или во всяком случае сравнимо с фреймворками.
Во-вторых, необязательно ориентироваться на негибкие системы, разработка кода под которые приносит только боль и страдания. Есть немало CMS с современными фреймворками под капотом. OctoberCMS (Laravel), Strapi (Node.js), Drupal (Symfony). Доступ к возможностям фреймворков при написании модулей/расширений/плагинов для CMS позволяет кодить почти так же гибко, как под фреймворк.
«Зачем мне платить за ненужные функции в CMS?»
- В общем-то, низачем. Возьмите бесплатную CMS (Drupal, WordPress). Вся сумма ненужных технологий будет стоить 0 рублей.
- Большинство этих ненужных функций не создают никакой, или создают минимальную нагрузку, пока вы их не используете. Либо их можно отключить.
- Иногда идти в CMS выгодно просто потому что, чтобы сделать то же самое на фреймворке, придется по сути воссоздать эту CMS. Что сложно назвать целесообразным.
«Хочу Python + FastAPI + Vue.js + Nuxt + Quasar + Tailwind + Postgres + Kafka + Centrifugo + …» Периодически встречаются такие ТЗ, где набор требований и деталей еще совсем не ясен, но список технологий уже жестко определен.
Есть лишь одна веская причина для такого жесткого выбора — вы (или ваша команда) являетесь экспертами именно в этом наборе технологий и планируете сопровождать проект самостоятельно, или даже участвовать в нём.
Во всех остальных случаях это несколько странно:
— Откуда эти требования, вам их на салфетке написал знакомый, когда обратились за консультацией?
— Они были в красивом КП от исполнителя, КП понравилось, а исполнитель не подошел?
— Вы где-то слышали, что именно эти слова модные и современные?
Правда в том, что для подавляющего большинства задач веб-разработки не существует единственно верного, безальтернативного стека. Такого что если выбрать любой другой, результат будет хуже. Вместо этого есть несколько популярных вариантов, и — внимание — вам подойдет любой из них. Гораздо важнее на данном этапе найти способных разработчиков, чтобы они сделали хорошо — на привычном им стеке. А ограничивая набор технологий вы мгновенно сокращаете количество исполнителей на порядок.
Среди разработчиков есть такой авторитетный специалист, Роберт Мартин. Апологет чистого кода, архитектуры, рук, стола и помыслов. В своих книгах он рекомендует вообще не выбирать никакую конкретную технологию, пока в ней не появилась необходимость, обусловленная явно сформулированными требованиями.
«Хочу Redis… и самопис!» Была у нас и такая заявка. Честное слово.
На самописе останавливаться подробно не стоит: даже просто использование фреймворка вместо CMS — это другой порядок стоимости разработки. А переизобретать всё своим самописом будет еще дороже. И имеет смысл разве что если вы — Гугл и вам надоели существующие языки программирования, поэтому надо изобрести новый. К проектной разработке это отношения не имеет.
В реальности клиент хотел сайт на 70% состоящий из операций с контентом. Но к этому контенту было необходимо прикрутить специальную логику, которая должна работать в реальном времени на вебсокетах. Клиент не очень знал, как это можно сделать, думал, что только самописом.
По факту весь проект удалось реализовать на все той же CMS Drupal. Включая нестандартную логику на вебсокетах — её тоже с Друпалом подружили. Хотя, сказать по правде, после этого опыта я бы в следующий раз брал фреймворк, писать было бы попроще. Но тут контентная часть по бюджету на фреймворк не прошла бы.
«Хочу 1С-Битрикс! Это профессионально и безопасно» К нам периодически обращаются уже вовлеченные клиенты, по рекомендации. И тем печальнее видеть в их запросах — Битрикс, Битрикс, Битрикс…
Дело в том, что мы с Битриксом не работаем. Недавно ездил на конференцию по PHP, и там каждый раз когда где-то кто-то упоминал в разговоре Битрикс (а это происходило нередко), можно было как будто слышать негромкое осуждающее «бууууу» откуда-то сбоку. Да, многие разработчики не любят Битрикс. И мы, так получилось, тоже с ним не дружим.
Однако досадно не это. Досадно то, что в реальности нет ни одной инженерно-технической причины выбирать именно Битрикс вместо другой популярной CMS. Напротив, можно назвать технические причины этого не делать: архитектурные архаизмы, сложность кастомизации.
Да, у Битрикса есть сертификат ФСТЭК. Но, к сожалению, он не работает как волшебный артефакт в компьютерных стратегиях — «Дай его герою и код будет неуязвим к взлому». Так что сертификат никак не мешает системе радовать нас новыми уязвимостями. А вот популярные в остальном мире CMS пережили истории с массовыми взломами ещё в прошлом десятилетии.
В общем с моей (и не только) точки зрения основная проблема в том, что маркетинговые таланты компании 1С и команды Битрикса в России ушли далеко вперед от технических преимуществ системы. Поэтому и досадно видеть в очередном ТЗ требование Битрикса для обычного контентного многостраничника, который можно сделать вообще на чём угодно другом и будет как минимум не хуже. В меру сил пытаемся переубеждать. Получается, конечно, не всегда.
Заключение
Вместо вывода хотелось бы еще раз подчеркнуть. Современные CMS далеко не такие деревянные и далеко не всегда целесообразно бежать во фреймворки, едва заметив намек на нестандартную логику. Попробуйте вместо этого прикинуть, не перевешивает ли набор полезных для проекта функций CMS те части логики, которые придется писать вручную. Возможно, удастся сэкономить и время, и бюджет.
И не забывайте, опыт и способности команды гораздо важнее конкретных названий волшебных технологий, которые вы могли где-то слышать.
Спасибо за внимание.
