Написание собственной CMS — это как держать у себя дома слона.
Для большинства людей гораздо проще сходить в зоопарк.
В 2000-м я обучался в университете и работал Интранет-разработчиком: публиковал в Интранет контент, написанный на статичном HTML. Это была моя первая «программистская» работа, и я ею наслаждался. Пару недель.
Потом стало очевидно, насколько мои обязанности являются однообразными и неавтоматизированными. И я начал писать приложение на классическом ASP, которое позволяло бы пользователям самостоятельно управлять контентом. Я и понятия не имел о существовании такой штуки, как Content Management System, и потому изобретал велосипед. В то время существовало всего несколько коммерческих CMS, зачастую стоившие сотни тысяч долларов. Учитывая распространённость и ценовой диапазон этой категории ПО, неудивительно, что не я один пытался уменьшить свои неудобства и повысить эффективность, создавая собственную CMS.
К 2004-му почти каждое интернет-агентство создавало собственную CMS, нередко кастомизируя под конкретных клиентов. Это приводило к появлению десятков модификаций — кошмар с точки зрения управления. «Это бессмысленно», думал я. К тому моменту я уже написал несколько специализированных CMS и снова заскучал. «А что если написать CMS, которая может быть полезна для любого сайта?» В результате я организовал компанию Kentico Software, чья миссия была очень проста: создать CMS, которую любой разработчик в мире может использовать для создания любого сайта.
Сюрприз: люди всё ещё пишут собственные CMS!
13 лет спустя меня ещё поражает количество людей, которые пишут собственные CMS. Существует масса зрелых продуктов, под все виды проектов: от open source до коммерческих систем корпоративного уровня, от лучших в своём классе до универсальных «всё-в-одном».
Так зачем кому-то до сих пор нужно писать собственную CMS?
Ответ прост: люди делают это из-за разочарования.
Традиционные веб-ориентированные CMS чреваты недостатками и ограничениями. Но правда в том, что все эти разочарования уже утратили актуальность. Знаю, звучит лицемерно. Ведь мне помогло написание своей CMS, так почему это не поможет другим?
Позвольте объяснить.
Самописные CMS устарели из-за headless-архитектуры
За последние 15 лет рынок CMS и технологии начали идти в ногу с изменениями цифрового ландшафта и пользовательскими ожиданиями, связанными с многочисленными разнообразными устройствами.
И сегодня новое поколение CMS-технологий — облачные, с headless-архитектурой — скоро совершит революцию в сфере управления контентом. В отличие от традиционных решений, headless-CMS сосредоточены только на управлении контентом и на том, чтобы сделать его доступным любому приложению посредством API. Поскольку у таких продуктов нет «головы» (head), которая обычно диктует, как нужно отображать контент, headless-CMS оставляют вопрос дизайна полностью на откуп разработчикам.
Поэтому не слишком разумно сегодня писать собственные CMS — если только вы не хотите стать вендором таких продуктов. Но мне легко говорить. Ведь я же не единственный, кто столкнулся с многочисленными недостатками и нашёл много причин, по которым самописная CMS может быть выходом из ситуации.
Так что давайте рассмотрим основные причины недовольства разработчиков и выясним, почему же они устарели.
Причина №1: стандартные CMS ограничивают мой творческий потенциал
Первое, на что жалуются фронтенд-разработчики, это вмешательство CMS в их HTML-код и необходимость искать обходные решения.
Но с этим покончено: headless-CMS дают вам полную свободу и никак не влияют на результирующий HTML-код. Для извлечения контента из репозитория вам достаточно лишь с помощью своего любимого языка программирования вызвать соответствующий REST API.
И более того, вы сами полностью решаете, как будет этот контент отображаться!
Причина №2: интерфейсы стандартных CMS слишком сложны
Многие традиционные CMS в последние десять лет существенно разрослись. Хотя все они начинались с идеи предоставления замечательного решения по управлению контентом, большинство не смогли избежать «ползучего улучшизма», поскольку они проникли в электронную коммерцию, автоматизацию маркетинга, системы бронирования, почтовый маркетинг и так далее. Хотя для кого-то удобно иметь всё в одном месте, но новым пользователям трудно изучать такие CMS. Большинству нужно всего лишь управлять контентом, избыток опций снижает продуктивность.
Новые headless-CMS создаются исходя из другой предпосылки: это всего лишь один из фрагментов мозаики микросервисов, и потому эти продукты обладают пользовательским интерфейсом, оптимизированным именно под управление контентом. В то же время современные CMS предоставляют API управления контентом, позволяющие создавать собственные интерфейсы редактирования поверх их репозиториев контента. Это удобно, если вы хотите создать более специализированный интерфейс или интегрировать в приложение возможности по редактированию контента, а не перенаправлять пользователей в другой интерфейс.
Причина №3: стандартные CMS слишком дороги
«Мы не хотели платить Х рублей за коммерческую CMS, поэтому решили написать свою». Если вам не нужно что-то гораздо более простое, чем реальная CMS (вроде управления списком новостей), в долгосрочной перспективе вы не сможете сэкономить с помощью самописной CMS.
Сегодня можно выбрать из массы бесплатных CMS с открытым исходным кодом, или воспользоваться облачной headless-CMS, чья ценовая политика учитывает особенности потребления, что всегда будет выгоднее разработки и использования собственной системы.
Причина №4: стандартные CMS не безопасны
Для многих организаций обеспечение безопасности CMS является кошмаром. Поэтому некоторые разработчики думают: «Если мы напишем свою CMS, то хакерам будет труднее найти в ней баги».
Классическое обеспечение безопасности через неясность (security by obscurity).
Да, хакеры могут воспользоваться известными прорехами в безопасности, но широко используемые CMS обычно тщательно тестируются. И обычно основным источником проблем является неприменение в компаниях свежих фиксов различных применяемых плагинов.
С облачными headless-CMS у вас всегда будет самая свежая версия. CMS хостится напрямую у вендора, который прекрасно знает как код, так и инфраструктуру, и может уделять соответствующее внимание вопросам безопасности.
Причина №5: стандартные CMS не вписываются в мою архитектуру
В определённых ситуациях это было справедливое замечание. Наиболее традиционные CMS предназначались к использованию в качестве центральной платформы, на которой всё должно строиться. Это означало, что код вашего приложения был тесно связан с CMS, как это проиллюстрировано выше. Вы были ограничены своей CMS-платформой, языком программирования, циклами обновления, масштабируемостью и безопасностью.
Не удивительно, что множество программных архитектур не могли следовать по этому пути! Приходилось создавать прокси-слой между CMS и приложением, или — сюрприз! — писать свою собственную CMS.
К счастью headless-архитектура позволяет легко обращаться к контенту с помощью API и писать свои приложения так, как вам хочется.
Причина №6: многие клиенты всё ещё пользуются написанной нами CMS
Многие цифровые агентства продолжают поддерживать свои CMS ради клиентов. Некоторые делают это намеренно, чтобы привязать к себе клиентов, которые не смогут так просто перейти к другому агентству.
В целом использование агентствами собственных CMS не даёт никаких преимуществ. Если они не стремятся стать CMS-вендорами, то им лучше как можно скорее отказаться от самописных систем. К счастью, во многих агентствах уже есть понимание, что это тупиковый путь и что они не могут быть конкурентоспособными с проприетарными системами. Но они боятся прыгнуть в неизвестность и перевести клиентов на стандартные CMS. В каких-то случаях это эмоциональное или политическое решение. Например, если CMS была написана основателем компании много лет назад, или это детище лучшего разработчика, который, ко всему прочему, ещё и единственный, кто знает, как оно работает.
Мой совет: сделайте этот смелый шаг, пока ваше агентство не проиграло!
Выберите современную CMS и выделите основные преимущества, которые привлекут к ней ваших клиентов. Наконец, дайте своим разработчикам новую игрушку! Подсказка: большинство из них очень быстро влюбятся в headless-CMS.
… и две причины, когда использование самописной CMS оправдано
Честно говоря, всё же есть ситуации, когда использовать собственную CMS либо целесообразно, либо это вообще единственный возможный вариант:
• Управление контентом — основа вашего бизнеса: если вы компания наподобие Medium, то вам наверняка нужен абсолютный контроль над системой управления контентом. Если вы большое издательство с десятками публикаций, и вам нужен полностью кастомизированный рабочий процесс, то вам тоже может понадобиться собственная CMS (или хотя бы кастомный редакторский интерфейс). Однако в мире ОЧЕНЬ мало компаний, относящиеся к этим категориям и для которых оправданы подобные инвестиции.
• Уникальные требования по безопасности или соблюдению законодательства: опять же, существует немного организаций, вынужденных придерживаться специфических правил, когда речь идёт о хранении контента, обеспечении безопасности, программной архитектуре или инфраструктуре, и эти правила не позволяют использовать стандартные CMS.
Если что-то из сказанного — про вас, то помните, что каждый час, потраченный на создание своей CMS, это час, который вы могли бы потратить на создание конкурентного преимущества, а не на изобретение колеса.
Не пишите свою CMS, пока не возникнет очевидный бизнес-случай
Люди ВСЕГДА недооценивают объём работы по созданию настоящей CMS.
Возможно, в первый момент вы подумали: «Что такого сложного в CMS? Я просто возьму задокументированную базу данных и прикручу сверху интерфейс редактирования». Это лёгкий старт, но ещё не настоящая CMS. Когда вы начнёте добавлять уровни, например, моделирование контента, языковые варианты, рабочий процесс, разрешения, доставку контента, поиск и так далее, то обнаружите, что разрабатываете и управляете по-настоящему сложным решением.
Надеюсь, сейчас вам стало очевидно, что написание своей CMS — паршивая идея. Это замечательное упражнение в программировании, но не основа вашего бизнеса — если только вы не CMS-вендор.
Комментарии (37)
ainu
22.09.2017 15:26+1Окей, а как тогда будут получаться новые OpenSource продукты? Ведь первая написанная строчка в таком проекте де-факто «своя CMS».
zapimir
22.09.2017 20:51Самое смешное, что если следовать этому заклинанию «не пишите свои CMS», то тот же упоминаемый WordPress не появился бы. Он же далеко не первая CMS.
MOTORIST
22.09.2017 15:29+5В наследство достался зоопарк cms. Все разные, порядка 8, включая все популярные, кроме drupal. Ни одна из них не удовлетворяла потребностям, я уж не говорю про дырки. Написал болванку на yii2. Под каждый проект создаем ветку и накручиваем до нужной кондиции. Интерфейс пишется для людей, которые выкладывают материал. Если им, что то не удобно делать, то мы оптимизируем процесс. Все довольны, а сколько счастья в глазах =) и ни единого разрыва (пока никто не взломал, тьфу, тьфу).
Akdmeh
22.09.2017 17:11+7А какое ускорение идет!
Переписал проект с Wordpress на Yii2 — как минимум генерация страницы ускорилась в 10 раз.
Конечно, при этом теряется модульность и возможность быстро добавить нужный плагин в систему, но когда уже точно сформирован функционал, и знаешь, чего от него нужно — такой перевод сказывается очень позитивно.ninadinastiia
22.09.2017 17:56+1Очень многие разработчики говорят о реальном ускорении, после перехода с CMS на фреймворк.
maxfox
22.09.2017 16:12+7А может кто-нибудь рассказать про эти headless cms? Это вроде облачной БД с REST API и веб-интерфейсом для редактирования? А я у себя на сервере (ну, можно и на клиенте) через API получаю данные и генерирую HTML?
Если у кого-нибудь есть опыт работы с такими штуками, расскажите пожалуйста. А то в гугле по запросу «headless CMS» гораздо больше странных статей вроде этой, а реальных продуктов с нормальной документацией — не густо.stardust_kid
22.09.2017 18:02Тот же самый Wordpress можно использовать как headless, если включить REST API. А дальше все как вы описали. Никакой революции тут нет, просто сегодня React позволяет комфортно работать в таком формате.
Yamanu
22.09.2017 17:11+2Согласно вашему утверждению, не стоит жить ибо жизнь ведет к смерти.
ninadinastiia
22.09.2017 17:54Полностью с вами согласна. Автор отговаривает людей от разработки… наоборот, это дает очень много опыта, и ник то не отменял успешных проектов, кто то ж когда-нибудь сделает удобную CMS…
shurph
22.09.2017 17:40Начали использовать похожий подход у себя. Даже не знали, что это называется модным термином headless-CMS :-)
Пользуясь случаем, хотелось бы узнать, кто какие headless-CMS использует на «бэкенде»? Интересуют свободные standalone решения.
Мы же у себя, на данный момент, остановились на Wagtail в качестве «бэкенда». А в качестве «фронтенда» используем обычное Node.js приложение для пред-генерации страниц для React'а (тот самый server side rendering).
Wagtail — это CMS, построенная на базе Django.
По первым впечатлениям: Wagtail больше заточена для использования её как «классической» CMS, однако имеет встроенный REST API (использует Django REST Framework), позволяющий забирать нужные сущности. Хотя, этот API достаточно негибкий: чтобы получить нужный набор полей сущностей, да ещё и с нужной глубиной вложенности связанных объектов, приходится достаточно много писать кода, обильно снабжая его копипастой из ядра Wagtail.
Интерфейс управления контентом и его редактирования в Wagtail достаточно удобный «из коробки», есть интересная система виджетов. Однако, опять же, для сложных кастомных виджетов приходится писать изрядное количество кода, да и UX начинает страдать.
Мы ещё не достаточно глубоко завязались на этом решении, поэтому было бы классно узнать о хороших альтернативах.
tema_sun
22.09.2017 18:35+1Django в целом и DRF в частности настолько удобный и мощный инструмент, что я не понимаю зачем на их осонове делать не проекто-заточенные CMS. Если уже ставите django, то вам в любом случае нужен разработчик, который в нем разбирается. А если есть такой разработчик, то зачем нужны псевдо-универсальные решения? Они все-равно не подходят на 100% и их приходится тюнить под себя.
Мне кажется, если Wagtail из коробки не подходит, и с ним приходится сражаться, то лучше вообще его не использовать, а работать на голом django/drf.ninadinastiia
22.09.2017 18:40+1Согласна с Вами, Django и создана для тех, кому не подходит стандартный функционал CMS)
shurph
22.09.2017 19:42Wagtail даёт достаточно удобный интерфейс для управления контентом, на первый взгляд. Да, есть трудности по кастомизации этого интерфейса, но пока ещё не понятно, перевешивают ли эти трудности те усилия, которые придётся затратить на написание пользовательского интерфейса работы с контентом на голой джанге. Всё-таки, встроенный веб-интерфейс админки django обычным пользователям показывать нельзя.
У нас проект не настолько «контенто-центричен», чтобы писать CMS с нуля на джанге (или чём либо другом).tema_sun
23.09.2017 12:15-1Что касается встроенной админки, то у них это где-то в документации даже написано, что она не для обычных пользователей и им туда доступ давать не надо.
maxfox
22.09.2017 19:23Т.е. у вас CMS на базе Django отдает данные через REST, а React рендерит HTML на сервере? А чем это хуже использования Django и для рендеринга тоже? Какой профит дает React?
shurph
22.09.2017 19:59React на «фронтендовом» бекенде даёт такой профит, что после первой отдачи подготовленного на сервере специального HTML дальше пользователь работает с сайтом как с Single Page Application и данные для следующих страниц сайта уже забираются браузером пользователя непосредственно из API Wagtail'а.
Фактически, получается так называемое изоморфное приложение. Здесь можно почитать подробнее: Изоморфные приложения. Взгляд в будущее с React.
Такие вещи нужны, в первую очередь, тогда, когда вам нужно дать пользователю какой-то сложный интерфейс на странице, а не просто статичный кусок текста статьи, но, при этом, вы хотите, чтобы и поисковики вас хорошо индексировали, и у обычного пользователя статья загрузилась быстро, как будь то это обычный статичный блог-пост, а не SPA, которое может грузиться по несколько секунд.
maaGames
22.09.2017 18:41Пишу свою CMS. Только потому, что websitex5 для меня слишком неудобна. Ну и платная.
foxmuldercp
22.09.2017 23:00Вообще, клон твиттера что на рельсах, шо на джанге пишется за вечер. А вот бложик формата жж с тегами поисками френдами — уже требует интересных развлечений.
А вот с cms — мне интересно как логически решать вложенность страниц, как это делается легким движением руки в вордпрессе, например?maaGames
23.09.2017 07:18websitex5 и cms, которую я пишу, предназначены исключительно для сайтов со статическим контентом (результатом можно запаковать в chm файл, например). Т.е. френдов и прочего нет by design. Хотя, если статьи хранятся в БД, то найти по тэгам или id пользователей — не проблема (проблема, конечно, но сделаем вид, что не проблема).
В чём проблема со вложенностью страниц? Дерево построить вообще не проблема (как дерево папок в файловом менеджере, но каждая «папка» при этом может быть и файлом), из этого же дерева автоматически строится главное меню. Именно так и реализовано во многих CMS. Чуть сложнее, если нужно не дерево, а граф.
haldagan
22.09.2017 21:47+6How I built a CMS, and why you shouldn’t
In the past 15 years, I’ve written five Content Management Systems and built a leading CMS software company. Now let me tell you why you shouldn’t write your own CMS.
Персонаж, разрабатывающий ЦМСки и создавший компанию по разработке ЦМСок сейчас объяснит вам, почему вам не стоит писать свою. Лучше, конечно же, купить (у него).
Заголовок спойлераКуча спорных моментов в статье — почти на каждую причину в моем опыте есть либо контрпример, либо личные возражения.
developer7
22.09.2017 22:39Как всегда в советах что делать а сто нет обсуждаются не вершина пирамиды а середина. А на вершине всегда один и тот же вопрос (мало кто его себе кстати задаёт вначале).
А именно: Чего вы хотите получить в результате решения. Ну или как ваше решение может повлиять на результат.
Так вот исходя из объекта топика, можно определить задачи (скажем так очевидные, не очевидные каждый пуст ставит для себя сам):
1. Сделать типичный сайт стороннему клиенту
2. Сделать нетипичный сайт стороннему клиенту
3. Сделать один типичный сайт. Например вам в компании поручили сделать сайт компании.
Так что выбрать? Готовое или самописаное? Я просто хочу сказать, что постулат в заголовке ошибочен, т.к. предполагает выбрать одну стратегию и всё. Хотя для каждой стратегии оптимален свой вариант.
P.S. Я как то коллеге сказал — зачем изобретать велосипед. На что он дал мне толстый журнал — новинки велосипедов за такой то год. Коллега увлекался велоспортом.
P.S.S. Когда появился google — уже существовали серьёзные поисковики. Когда появился facebook — уже существовали сайты для общения.
P.S.S.S А теперь всё вышесказанное выкинте из головы (ну или просто положите в архив памяти) как очередной совет типа топика. Есть одно правило прежде чем что то делать подумайте зачем и как. Ну или просто делайте.
boilroom
22.09.2017 22:39+1Сплошные призывы. Некоторая аргументация присутствует, с некоторыми тезисами я даже готов согласиться, но в целом больше похоже на рекламу. Причем, давно известной конфеты в другой обертке. Это я про «Headless CMS».
Если не ошибаюсь, изначальный автор статьи написал «Kentico CMS». Я с ней сталкивался. Давно. Ничего интересного и революционного в ней на тот момент (2012 г.) не было. Просто платная (очень платная) CMS для внедрения в бизнес-сегменте. Документация была запутанной. Чем-то все это напоминало «Битрикс» — много маркетинга и довольно средний продукт в красивой рекламной коробке. Это мое личное мнение, разумеется. Возможно, я просто не сумел оценить ее или с тех пор что-то стало сильно лучше. Своих денег, на мой взгляд, она не стоила.
Я таким конторам не очень доверяю.
edogs
22.09.2017 23:11Есть очень простая причина для создания цмс — занятие ниши рынка, получение на ней преимущества.
Создав продукт который лучше других решает задачи определённой ЦА — получаешь конкурентное преимущество для работы с этой ЦА. Будешь делать лучше, дешевле, быстрее — при прочих равных, но не вообще, а для данной ЦА.
Универсальных ЦМС как таковых быть не может, поэтому нишевой продукт всегда будет иметь спрос, если ниша конечно выбрана хоть немного с головой.
stychos
23.09.2017 01:38+1Какой-то пиар какого-то очередного конструктора на стороне.
pm_wanderer
23.09.2017 13:1950 процентов статей — это пиар)
Себя, своей библиотеки, предмета своего обожания.
Остальные 50 процентов: переводы чужого пиара)stychos
24.09.2017 00:02Да кто ж спорит-то. Просто аргументация у автора слабовата, на мой субъективный взгляд.
KirEv
23.09.2017 13:56чем больше кода — тем больше ошибок.
никогда не понимал зачем использовать готовое решение, при условии сроков не на вчера, если есть наработки (почти у каждого уверен они есть) простой, к примеру, админки, а на выходе: визитка, каталог, или интернет магазин.
Вот ты сделал чтото, например, на вордпрессе, или, прости Господи, на джумле, ну или на магенто… все работает, свежие патчи, десятки сторонних модулей и кучи-кучи-кучи кода под капотом в который вникать и разбираться не то чтобы не хочется, сроки в рамках проекта не позволяют…
… что с этими готовыми решениями будет? Кто будет следить за свежими апдейтами сторонних компонентов системы?
Были случаи, когда давний сайт на одной из известных ЦМС не обновлялся длительное время, в результате, из-за уязвимости в одном из модулей начались бесконечные емейл-рассылки с ВПС и заражение других сайтов… секс был еще тот все это вычистить.
Брать чужую цмс, пусть даже бесплатную, вижу в случаях:
— ограниченные сроки
— ограничен бюджет
— лень возится, проще взять готовое, тик-шмык и работает
— другие причины, типо, рук не хватает, ума не хватает и т.п.
У каждого свои методы работа, но как по мне, легче сделать свое простое с необходимым минимальным набором функций, чем использовать комбайн и следить за апдейтами и его компонентами.
aszhitarev
23.09.2017 14:20+4Никогда не пишите свою CMS потому что… Я написал свою CMS! И вы обязаны её купить потому что… Ну это же Я её написал, а я знаю, что вам нужно!
А ещё у неё нет головы.
tjomamokrenko
Когда, казалось бы, ну сколько ещё можно найти дыр в WordPress…
https://wordpress.org/news/2017/09/wordpress-4-8-2-security-and-maintenance-release/
3 дня назад вышел апдейт с фиксом 9-ти критических уязвимостей. Да, открытые CMS тестируются, но это не значит, что в них доселе нет глупейших уязвимостей, и это не значит, что я доверяю опыту тех программистов, которые писали WordPress Core.
Для более-менее серьёзной конторы надо очень подсуетиться, чтобы сделать из open-source CMS безопасную систему. Либо написать своё решение, если позволяет опыт сотрудников (писать безопасный, поддерживаемый, etc., etc. код) и поставленные процессы.
В моей компании пошли по первому пути. Я этому WordPress'у (как InfoSec Engineer) урезал почти всё, что можно, и не жалею.
zapimir
Ага, хотелось прям добавить после «тщательно тестируются»… ботами, ищущими кто не успел обновиться. Логи прям пестрят интресными запросами, несмотря, на то что не использую WordPress…