Вступление
Вот и пришло время подвести итоги нашей разработки. Эта статья станет заключительной в описании истории развития нашего проекта. Я постараюсь подробно рассказать о полученном опыте создания нового инструмента для построения веб-сайтов.
Миллионы web-проектов увидели свет, но изо дня в день программисты все еще пишут тонны исходного кода, решая похожие задачи на разных инструментах. Речь в этой статье пойдет о технологии, которую мы разрабатываем на протяжении 4-х лет. Я уже ранее рассказывал о том, какой была моя задумка и цель в создании данного продукта и чего именно я хотел добиться, программируя инструмент для повседневной рутинной разработки веб-приложений. Мне пришлось пройти свой путь от презентаций моего продукта на стартап-pitch'ах и хакатонах и до получения первого реального проекта в сети, где я смог успешно применить мою разработку.
Все началось в далеком 2017 году, когда мне пришла идея написать для себя сайт. Я, недолго думая, взял Drupal и настроил его как headless-cms. Мне хотелось написать отдельно фронтэнд и не копаться с темами от Drupal. Но что-то пошло не так! Я столкнулся с множеством ограничений в проектировании сущностей в административном интерфейсе. Тогда я решил попробовать это сделать на WordPress. Но я совсем не ожидал, что мне придется создавать отдельные контроллеры под каждый тип сущности. Но честно признаться - меня это расстроило. В Drupal хотя бы есть Views, которые относительно легко сконфигурировать в административной консоли и создать endpoint'ы для доступа через REST API, но тем не менее там есть свои ограничения. После этого я провел небольшой анализ существующих CMS и понял, что придется писать все под себя.
Без дальнейшего промедления, я срочно приступил к разработке своей CMS. В этой статье я дал описание того, что у меня по итогу получилось. Это была первая версия продукта. В целом, система управления контентом была реализована, но я увидел, что в этой версии огромная проблема с производительностью. И это мне дало новое понимание того, какие технологии мне выбрать для разработки второй версии и как решить проблему производительности.
Я жил этой идеей, решая в голове как проектируется следующий модуль или очередной класс и с удовольствием делился этим с окружающими. В итоге, общими усилиями с моим коллегой, мы смогли выдать интересную реализацию задачи - взаимодействие клиент-сервер, основанную на протоколе WebSockets. И это один маршрут передачи данных, с помощью которого, для формирования ответа в виде валидного HTML, ядру фреймворка передается инструкция.
На данный момент в MastermindCMS2 насчитывается 12-функциональных модулей, два из которых не активны и потеряли свою актуальность. Плюс ко всему этому существует отдельный проект Mastermind Microservices, включающий в себя интеграции сторонних проектов.
Что же в итоге может MastermindCMS2? Ниже я дам краткое описание функций каждого модуля по-отдельности и расскажу о том, как работает движок-шаблонов.
Модули
В основе MastermindCMS2 лежит обычный Spring Rest Controller. В дополнении для асинхронного взаимодействия между клиентом и сервером был использован Spring WebSocket Controller.
Application – модуль обработки HTTP-запросов.
Framework – модуль обработки файла шаблона и рендеринг тегов фреймворка, которые выполняют связку с данными.
Common – тут сложены все общие классы и инструменты, использованные в проекте.
Builder – модуль приложения с визуальным редактором для сборки страниц. На данный момент дальнейшая разработка не ведется, так как потерял свою актуальность.
Utilities – почти тоже самое что и Common, но еще имеет классы, использованные в проекте Mastermind Microservices.
Blogging – модуль содержит структуры и сервисы для блогов.
Commerce – модуль покрывает функционал для электронной коммерции. Более того, структура объектов в базе данных спроектирована так, что без проблем можно расширять сущности прямо из административной панели.
EmailSender – тут название говорит само за себя, так как по сути это модуль, реализующий функционал отправки писем по электронной почте.
Messaging – здесь находиться функционал для построения мессенджеров и чатов.
FileStorage – здесь реализовано базовое взаимодействие с файлами или другими словами это файловый менеджер.
i18Next – модуль для мультиязычности.
VCS – версионирование шаблонов, интеграция с Git. На данный момент дальнейшая разработка не ведется.
Основная концепция
Любой сервис, который написан на Spring и существует в веб-контексте сервера, можно будет вызывать через клиентскую часть фреймворка, а ответ получать в виде JSON или выполнять обновление HTML. Cуществует два способа использования фреймворка.
Первый способ, или основной способ — это когда data binding реализуется через SSR (Server-Side Rendering) и клиентская часть фреймворка используется для обновления HTML.
Второй способ, или дополнительный — это когда data binding реализуется через сторонние фреймворки, такие как Angular, React, vue.js и т. п., а фреймворк MastemindCMS2 предоставляет универсальный канал получения данных в виде JSON, используя WebSocket в качестве протокола.
Поэтому, проектируя свое приложение, вы не ограничены в выборе фреймворка. MastermindCMS2 дает дополнительную свободу в реализации задач. Вам не нужно работать с данными на клиенте - это уже сделано за вас! Остается только связать дизайн с функционалом.
В отличии от Spring Data REST, в MastermindCMS2 реализованы готовые методы для управления данными.
Теги
В MastermindCMS2 существует 8 типов тегов. Этого вполне достаточно для создания динамических шаблонов. Многие сравнивают его с известным Spring Thymeleaf. Безусловно, схожесть есть, но также есть и важное отличие, из-за которого я не стал использовать этот фреймворк в качестве языка шаблонов. На одном из этапов разработки я даже рассматривал интеграцию Spring Thymeleaf в общую систему MastermindCMS2. Так в чем же все-таки различие? А различие состоит в том, что для Spring Thymeleaf нужно писать контроллер для каждой view отдельно, которая в свою очередь повлечет за собой связку части фронтэнда с бекэндом. И тогда MastermindCMS2 теряет универсальность и абстрактность.
На сайте mastermindcms.co в разделе документации вы можете ознакомиться с каждый тегом, а также узнать, как работает клиентская часть фреймворка.
Роутинг
Если задача состоит в реализации сайта с одностраничной навигацией, то во фреймворке уже существует возможность, при которой вы можете подгружать HTML-фрагменты по определенному роуту. Это часто используется там, где нужна скорость и удобство подгрузки данных, например, для построения административных интерфейсов.
Сегментация разработки
Во фреймворке фронтэнд и бекэнд никак не связаны. Это позволяет четко разделить команды на фронтэнд и бекэнд разработчиков.
У нас на проекте были фронтэнд разрабы со знанием только веб стека HTML/CSS/JS и они успешно справлялись с задачами.
А с появлением Mastermind Microservices появилось еще больше гибкости и независимости команд.
Заключение
В заключении я бы хотел написать несколько слов про результат работы над проектом MastermindCMS2.
Я никогда так много не работал над проектами и никогда не получал так много нового опыта в работе. Все проекты, на которых я работал по найму, оставляли во мне лишь грусть и опустошенность после завершения. Все, что было запланировано для реализации идеи, было реализовано. Референсный проект очень сильно «обкатал» технологию. Я очень доволен тем, что получилось в итоге. Конечно, история данного проекта не заканчивается - дальше еще много идей, которые я реализую с помощью этой технологии. И уже не будет вопроса, на каком технологическом стеке создавать новое приложение или вебсайт.
Если у кого-то появится интерес попробовать MastermindCMS2 или лично со мной побеседовать на тему дальнейшего развития фреймворка, то буду рад.
Хорошего и продуктивного вам дня!
