Левитация — а не отделить ли нам сайт от движка?

200 лет назад начались разборки с авто двигателем. Понадобилось 80 лет для создания двигателя внутреннего сгорания. Результатом разборок стало появление сразу двух индустрий — автомобилестроение и моторостроение.

20 лет назад появилось сайтостроение в виде фреймворков. Оно также началось с разборок с движком. Не с сайтом, с ним все было ясно, а именно с движком. И вот, похоже, разобрались. И с движком, и с сайтом.

Ныне фреймворки подобрались к естественному рубежу: отделение сайта от движка. Есть и достижение — первый российский (и мировой?) фреймворк Levitation с новой архитектурой.

Основная проблема нынешних фреймворков

Современные фреймворки основное внимание уделяют движку. Сайт для них является менее значимым потому, что с ним все более-менее понятно: html, css, js + шаблонизатор. А вот с движком не все было понятно, и основные усилия были направлены именно на движок. Причем на движок, который, естественно, управляет только одним сайтом.

В результате все популярные ныне фреймворки являются моно-сайтами, то есть их движок управляет одним сайтом. В их корневом дире всегда сидит `index.php` — это стартер их единственного сайта. Более того, многие компоненты сайта — конфиги, шаблоны, коды оказываются там же, где и компоненты движка. Результат такого сверх-внимания к движку — полное растворение сайта в движке!

Чтобы сделать бэкап, надо бэкапить все — не только сайт, но еще и движок! Чтобы сделать dev сайт — надо копировать все! А ведь все — это для сайта в 0.5-1 Mb еще и 50-100 Mb движка. Движок в сто раз больше полезной нагрузки!

Проблема с бэкапом сайта решалась легко — спец класс или утилита для бэкапа именно сайта.

А вот проблема `мультисайта`, которая во весь рост встала лет 10 назад, оказалась вообще говоря нерешаемой. Нерешаемой из-за того, что единственный сайт был напрочь растворен в движке, и чтобы вытащить его, надо было переписывать все! Однако переписать все — это уже не новая версия, а новый фреймворк. Компромисс нашелся в варианте ограниченного мультисайта, когда все мультисайты могли находиться только внутри некоторого спец-дира в движке. При этом основной сайт в корне фреймворка естественно остался — без него никак.

Ну и вишенка — у топовых фреймворков, с которыми я знаком (WP, Laravel, Symphony, Drupal, Yii2) вообще нет объекта (класса) Site! Как вам такое?

Фреймворк Levitation – сайт отделен от движка

Лет 5 назад появился фреймворк Grav. Он не входит в топ 20, и может даже в топ 50, но довольно продвинутый. В нем класса Site тоже нет, но зато есть шаг в верном направлении — конфиги движка и сайта разделены. Остался последний шаг — разделить коды движка и сайта.

Небольшая команда энтузиастов решилась на радикальную переделку Grav – переписать его с целью полностью отделить сайт от движка.

Это не было легкой прогулкой, но результат оказался впечатляющим:

  • сайт отдельно, движок отдельно,

  • любой сайт может обращаться к любому движку,

  • регулировать нагрузку на движок — без проблем,

  • dev сайты и движки — да сколько хочешь,

  • бэкап сайтов и движков — просто копируй/архивируй,

  • разграничить доступ разработчиков и техподдержки — один клик,

  • и вообще — один движок, много сайтов — это и есть мультисайт!

Назвали мы свой фреймворк оригинально: Lev или Levitation (Лев или Левитация). Это просто дань уважения к его предку Grav (Gravitation).

Достоинства Lev

Супер-скорость

По сравнению с другими фреймворками Lev отвечает на запрос не быстро, а мгновенно. И это связано не с тем, что архитектура и все сторонние компоненты Lev самые современные, нет. И даже не с тем, что система кэширования страниц — самая крутая (хотя это так и есть).

Супер-скорость связана с тем, что Lev не использует СУБД. Почему не использует? – Да потому, что нафиг просто не нужна! Об этом – ниже.

СУБД? – не нужна!

А зачем фреймворку СУБД? У фреймворка собственно только две основные функции. Первая – анализировать запрос браузера, вторая — формировать и возвращать ответ (html страницу). Спрашивается, а где здесь СУБД? А ее здесь нету. Есть файловая система и алгоритмы формирования страниц по запросу. Все.

Почему же тогда все топовые фреймворки не просто содержат СУБД, а еще и считают ее важнейшим своим компонентом? Да потому, что СУБД нужна для обработки больших данных. А большие данные могут появляться только в больших приложениях, типа магазинов, корпоративных сайтов, вики,… Ключевым здесь является слово `приложение` — СУБД нужна приложениям с большими данными.

А вот фреймворку для исполнения его базовых функций СУБД не просто не нужна – она противопоказана. Фреймворку нужна только файловая система сервера, которая однозначно быстрее любой СУБД.

Ультра-современные архитектура и компоненты

Lev – наследник Grav, а Grav — довольно свежий фреймворк, ему около 5 лет. Grav воспринял все достижения, наработанные своими предшественниками. Общая компоновка и все основные компоненты фреймфорков к моменту появления Grav были многократно отработаны. Grav собрал все самое лучшее.

А Lev просто добавил к этому последний архитектурный штрих — полностью отделил сайт от движка. Правда, для этого пришлось переписать ядро Grav.

Потоки вместо путей

Для управления файлами и директориями Lev использует систему управления потоками (streams), а не путями, как у большинства фреймворков.

Потоки гораздо удобнее, чем пути, потому, что позволяют определять не только собственно пути, но и дополнительные параметры типа `чтение-запись`, `только чтение`.

Но важнейшим достоинством потока является возможность определить его путь относительно другого потока. И даже относительно нескольких потоков. Собственно именно в последнем и кроется вся мощь управления потоками.

И вишенка — все основные операционки поддерживают не только пути, но и потоки.

Дружественный конфиг – yaml файлы

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

А вот внешние настройки определяют режимы взаимодействия с внешним миром. И их лучше выносить из кода. Еще лучше отделять их от внутренних настроек. А еще лучше их декларировать не на языке программирования, а как-то более дружественно. Отличный выбор — `yaml` формат. Он легко понятен даже юзеру. Правда, прогеры не всегда с ним дружат за его фривольность, но это их проблемы. Тем более, что внешние настройки – вообще не их забота.

Компактность – ничего лишнего

Времена, когда во фреймворк пихали все, что типа может понадобиться – эти времена прошли. Индустрия развилась, специализация рулит. Фреймворк должен содержать только нужные ему самому компоненты – и ничего больше. Всякие дополнительные фичи (типа СУБД), нужные конкретному приложению, оно может подключить само. Точка.

Так вот, Lev не просто компактен – он сверх-компактен. Дистрибутив весит ~20 Mb. Из которых более половины — вендоры. Это без админки. А с админкой — еще ~20 Mb.

Разделение сайта и движка

Главной фишкой Lev является полное разделение сайта и движка. Сайт Lev сидит в своей собственной директории. Сидит весь, со всеми своими потрохами. То же относится и к движку Lev.

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

Взаимодействие сайт-движок такое:

  • Сайт получает запрос браузера и передает его на обработку движку.

  • Движок анализирует запрос браузера и формирует html страницу ответа, обращаясь к настройкам, шаблонам страниц и бизнес-логике приложения вызвавшего его сайта.

  • Движок возвращает сформированную страницу браузеру.

Мультисайт – полный и неограниченный

Благодаря разделению сайта и движка Lev поддерживает неограниченный мультисайт: один движок — много сайтов.

Такая архитектура имеет множество выгод.

Самой очевидной выгодой является бэкап – просто делаешь копию или архив директории сайта, и никаких проблем.

Другая выгода касается разработки и саппорта. Разделение движка и сайта автоматом приводит к разделению специализаций. Разработчики и саппортеры естественным образом делится на две разных группы по интересам – разработка и саппорт собственно сайта, и разработка и саппорт движка. И, что совсем хорошо, рабочие площадки группы сайта и группы движка не пересекаются — у каждой своя директория!

Ничто не мешает иметь не один движок, а сколько угодно, исходя из нагруженности, безопасности, бизнес-значимости, разработки/сопровождения и т.д. При этом все движки будут абсолютно одинаковы (в рамках одной версии).

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

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

В общем, никаких ограничений для любой архитектуры пар сайт-движок!

Это как в автомобилестроении 100 лет назад, когда двигатель отделился от авто, а индустрия моторостроения — от автостроения.

Lev отделил сайт от движка — и это правильно!

Проект Levitation

Приветствую каждого, кто добрался сюда!

Проект Levitation еще совсем молод, но он уже передовой и он чисто российский!

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

Если Вы желаете поддержать Levitation любым образом, включая спонсорство или участие в разработке, вот контакты:

Сергей Гусев, sdgus@mail.ru

https://github.com/getlev/lev


ссылка на оригинал статьи https://habr.com/ru/post/672380/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *