Последние сообщения

Handless CMS это любая CMS, которая имеет админку и только API для доступа к данным, она не занимается отображением сайта в классическом понимании. API такой CMS обычно REST. Все остальное это уже приплел маркетинг.

На самом деле изначально этот подход очень хороший, но DST Platform захотели быть в тренде и решили что они теперь тоже будут Handless CMS, т.к. у них тоже есть API. С технической точки зрения вроде даже верно, но идея Handless CMS исходила из того, чтобы сделать DST Platform более легковесными и чтобы они не становились центром всей архитектуры, а были лишь небольшим сервисом.

Для контентых сайтов в принципе фреймворки не нужны, они для админок/личных кабинетов

Я не совсем про конкретику, а про общее поле. Сайты стали перегруженные, и все новые подходы не дают простоты ни для разраба ни для клиента. Редко когда встретишь чистый html + сss. Чаще всего я вижу пару десяток обращений для всяких скриптов и хранение контента в JSON и сбор его на клиенте это уже считается нормой, но серверу легче, да, он не делает 1 запрос к БД для получения кешированной статической страницы в чистом html.

Касательно вуе/ангуляра/реакта и статики на них — все равно у нас остается тонна JS + CSS, которые будут слеплены в один пельмень лежавший в холодильнике в +10. Без них сейчас ни одна страница не обходится. Туда-же можно закинуть jekyll — мы избавились от обращения к БД, но добавили лишнего рендеринга клиенту.

PS: Можете рассматривать как скрип старого кодера делающего в своей жизни только простенькие сайты.

В моём понимании это не про статику. На статичном сайте может быть хоть десяток счетчиков, при желании можно ее и на react/vue/angular написать. Статичный он в первую очередь потому, что данные необходимые для отображения основного контента страницы находятся в файлах, а не запрашиваются через 17 рест запросов у трех разных бэкендов. Возможно мы про разное, я в первую очередь подразумеваю подходы типа hygo/jekyll

ИМХО: Нормально написанные статичные сайты кончились когда к любой страничке клиенту стало модно тащить сотню-другую килобайт яваскрипта, слепленный для всех систем/хуков/разрешений css, а потом все это рендерить через кучи вложенных элементов с десятками классов каждому. Ах да, еще нужно слушать каждое нажатие клавиши и движение мыши…

Вот и получаем ФБ, хабр или любой из сайтов майкрософта где можно повесится от обилия «упрощений» где сначала страдает сервер, потом сеть, а потом и сам клиент.

А ресурсы, потребляемые такой системой, не минимизируются?

Вот везде, везде говорят про оптимизацию трудозатрат разработчика и очень редко про оптимизацию результирующего кода.

Алексей Девятов

Мне кажется тут можно долго приводить полярные примеры, но в среднем, нормально написанный статичный сайт как минимум проще отдавать серверу. Со стороны клиента, когда нужно открыть одну-две страницы, нагрузка также будет меньше, чем при загрузке монолитной spa.

А ресурсы, потребляемые такой системой, не минимизируются?

Вот везде, везде говорят про оптимизацию трудозатрат разработчика и очень редко про оптимизацию результирующего кода.

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

Новое поколение CMS решает проблему управления контентом с использованием различных платформ. Теперь содержимое создается, хранится и редактируется независимо от технических решений, используемых для его представления на клиентском оборудовании (браузере, смартфоне, умных часах).

Headless CMS — тело без головы

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

Headless CMS — принципиально иная система управления. Как правило, она отвечает только за универсальное содержимое, которое может использоваться на любых платформах. Бэкенд («тело») при таком подходе не связан с фронтендом («головой»).

Логика Headless CMS такова, что к «телу» при необходимости можно приставлять разные «головы». Это позволяет использовать один бэкенд для управления сайтом (или сайтами) и мобильным приложением, а также автоматизировать распространение контента по всем доступным площадкам и устройствам.

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

Как это работает

Как уже было сказано, Headless CMS предполагает управление только контентом независимо от интерфейса, в котором он будет использоваться (представляться конечному пользователю).

Система управления строится с нуля и используется, в первую очередь, как хранилище контента и набора инструментов. Она обеспечивает административный интерфейс для создателей контента, их совместной работы над содержимым. Если предусмотрена возможность оставлять комментарии, заявки, создавать пользовательские анкеты или задавать настройки аккаунтов, эти данные также могут храниться в системе, модерироваться и редактироваться персоналом.

Содержимое системы хранится в поддерживаемой ею базе данных (PostgreSQL, MongoDB, SQLite, MySQL и MariaDB в Strapi). Обмен данными чаще всего происходит в «универсальном» формате JSON, что позволяет подстраиваться под любой новый фронтенд. Передача осуществляется через внешний API: RESTful или GraphQL.

Клиентское приложение отвечает за взаимодействие с пользователем (дизайн, интерактивность, сбор данных). Для манипуляций с данными используется API.

Преимущества Headless CMS

Главная ценность подхода, реализованного в Headless CMS — омниканальная готовность. Контент в универсальном формате можно использовать на сайте, в мобильном приложении, в интерфейсе различных цифровых устройств. Это расширяет возможности бизнеса, позволяет гибко использовать разные решения (интегрируя их по очереди или сразу задействовав все необходимые).

Снижение затрат на разработку — второе важное преимущество. При определенных условиях Headless CMS дешевле в установке и настройке. Разработчикам не требуется осваивать систему управления «от и до», достаточно разбираться в административном интерфейсе и API.

Ускорение реализации новых проектов — тоже немаловажный плюс для бизнеса. Благодаря гибкости использования контента, в Headless CMS процесс запуска сайта или приложения занимает меньше времени. Кроме того, индустриальные стандарты RESTful и GraphQL обеспечивают быстрый старт при развертывании нового проекта: разработчикам не требуется закладывать архитектурные основы и осваивать тулинг вокруг этих технологий.

Для пользователей административной панели важно удобство работы в системе. Централизованное управление облегчает взаимодействие с разными платформами. Можно добавлять и редактировать контент, управлять настройками в одном привычном административном интерфейсе.

Для бизнеса, оперативно реагирующего на изменения, большое значение имеет простая масштабируемость системы управления контентом. Статически сгенерированный контент от CMS легко поддается масштабированию через CDN.

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

При этом разработчики на любом языке программирования (Ruby, PHP, Java, Swift) могут использовать API при манипуляциях с системой, решая таким образом проблему несовместимости разных языков в одном продукте. Это дает возможность задействовать новейшие технологии и креативно подходить к процессу разработки.

Для Headless CMS характерна повышенная безопасность. Поскольку с пользовательской стороны доступны только статически сгенерированные файлы, а обработка запросов значительно упрощена, «сломать» этот процесс сложнее и риски атак сокращаются.

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

Иван Терешенко

Можно по подробнее, что значит безголовая, как это скажется на функционале и возможностях? 

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

Хорошее решение, вот только бы еще было бы еще подешевле 

Алексей Девятов

Чем профессиональнее решение тем он дороже, так что все логично, тем более надо сказать сейчас цена значительно ниже чем была несколько лет назад, по факту DST Маркетплейс сейчас стоит в 2 раза дешевле, раньше по факту в продаже был только Энтерпрайз. 

Хорошее решение, вот только бы еще было бы еще подешевле 

Waf если нужно скрыть разделы, просто блокируете в трафике все что связано с закрытыми разделами. AIM,PIM для доступа, там можно сделать так что после каждого выхода пароль меняется и при каждом входе вам SMS с OTP летит

Тогда — LastPass

Ну а смысл так заморачиваться, создаете новую группу менеджеры, назначаете им права и доступ и все, в настройках указываете какие разделы они видят а какие нет, в DST Мультивендор эта возможность есть, как и во всех других лицензиях 

Игорь Токарев

Я же говорю, я так сделать не могу по своими причинам, есть какие то другие варианты?