Comments 67
Если нужен headless cms - смотреть в сторону lumen. А так непонятно зачем использовать фреймворк на который не найдешь разрабов. И дружественный YAML конфиг - он не дружественный. В последних версиях symfony это поняли сейчас конфиг - php файлы
Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем vendor со всеми пакетами лежит в репозитории?
Ахаха, я понял. Это же импортозамещение. После того как я почитал ридми на русском, то, честно говоря, думал что Грав там будет в в зависимостях. Но тут всё гораздо смешнее: берём Grav Framework, устанавливаем, и начинаем хачить свой левиафан — или как его там — прямо по живому. Так в 90-е игры русифицировали. То есть по своей сути — это инсталляция Grav Framework в которой что-то допилили руками. Жаль, у меня страница загрузки не открывается, но я на 100% уверен, что там никакого композера и никакого даже гит клона — только зип архив, только хардкор!
В чем-то вы правы. Первое время Grav был вендором Lev. Затем решили от этого отказаться. Grav сейчас не вендор, а предшественник. Из вендоров уберем.
"Есть и достижение — первый российский (и мировой?) фреймворк Levitation с новой архитектурой"… который "является расширением Grav, причем небольшим".
Когда видишь такое трескучее начало — уже на автомате ищешь мелкий шрифт. И что характерно — находишь.
Вы молодцы! Крутая работа!
Спасибо, @gr33tx!У тебя карма тоже не блестит, вижу. Молодец!
"Движок" в соседней дириктории - это понятно. А что имеется в виду "движок" на другом сервере, и как это организовывается?
Сервера имеют имена, в Винде буковки с:/, d:/, … Вам лучше обратиться к своему саппорту.
А с обоями как, не скучные?
Честно прочитал всю статью, так и не понял что автор называет движком, что сайтом и мкльтисайтом, почему это магазины вдруг стали все бигдатой, и для каких областей вообще этот фреймворк. Стоило бы начать с этого, а не с бесконечного повторения про бэкапы, мультисайты и передовые отечественные разработки. Вы же на техническом ресурсе вроде-бы, а не на региональном телеканале рассказываете про болгенос и чудо флешку-маркер. Не надо изобретать термины, но если реально надо то дайте им четкое и понятное определение. Сайт это фронтенд? Движок это система кэширования страниц? Фраза про отсутствие класса Site на популярных фреймворках вообще убила. Очень уж помпезно построена. Звучит как "каждый более менее уважающий себя фреймворк должен иметь класс Site". А он нужен? Для чего? И вот так со всем в статье, какие-то непонятные мотивы и задачи, понятная одному только автору терминология, надуманные проблемы и их героическое решение.
Сайт — это фронтенд, движок — это не только система кэширования, а весь бэкенд.
Класс Site нужен для инкапсуляции всех свойств и методов объекта сайт. Объект Site есть на экране браузера, но его почему-то нет в фреймворках. В нынешних фреймворках свойства и методы сайта распылены по разным конфигам и классам. Это результат (вполне естественный) первого этапа развития сайтостроения, когда отрабатывались подходы к управлению одним сайтом. Вроде отработали...
Проект Lev говорит простые вещи: сайт есть самостоятельная сущность, сайт и движок — разные сущности. Давайте это осознаем и разделим их. Как то так...
Я вам скажу прямо - у вас низкий уровень понимания технологий и вы слабо разбираетесь в теме программирования (как минимум web), однако, наверняка считаете, что вы серьёзный программист и написали что-то грандиозное. Вам предстоит ещё долгий путь познания.
Даже сама терминология, которой вы пользуетесь - неправильная. Например, тут можете прочитать что такое фронтенд, что такое бэкенд.
То есть вы разделили бэк и фронт? Так их уже давно разделяют, если есть потребность. Про класс site все ещё не понял, вы засунули весь фронтенд в один класс?
Я вижу так: у фреймворка есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет. А бизнес-логика - это основная задача сайта. Сайт магазина содержит приложение для магазина, данные по товарам в СУБД, и определения всех своих страниц.
Итак, если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов. Согласны?
Так вот, я знаю, что в топовых фреймворках нет класса Site, а во многих нет даже класса Engine. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
А насчет «вы засунули весь фронтенд в один класс?» даже не знаю, что сказать. Нет, не засунул. Я сторонник глубокой декомпозиции классов.
Теперь вы пытаетесь собрать маршрутизатор, все контроллеры и модели в один класс и обозвать его «сайтом», а все представления назвать «движком». Что даст такое объединение ежа с ужом?
Не совсем так. Запрос браузера получает сайт. И вызывает любой доступный движок для формирования ответа. Движок формирует страницу ответа (исходя из данных именно этого сайта) о возвращает ее браузеру.
Если сайт использует модель MVC, то "маршрутизатор, все контроллеры и модели" будут сидеть в сайте, а не в движке. И никакого объединения ежа с ужом тогда нет.
Я думаю, автор просто работает с одностраничными лендингами. И в его картине мира, "сайт" — это несколько статических страничек. Собственно, ниша "фреймворка" Grav — как раз такие сайты.
Вот отсюда ноги и растут у всех этих рассуждений, типа "движок больше сайта", "сайт не формирует страницы, а просто их определяет". И с этой точки зрения такой подход имеет право на жизнь. Действительно, если твоей студии заказали 20 лендингов, то делать 20 отдельных сайтов как-то глупо. проще действительно сделать мультисайтовый движок и тупо обрабатывать веб-сервером запросы к любым доменам, разруливая уже на уровне конфига по HTTP_HOST, какой конкретный сайт показывать.
Другое дело что это очень узкая ниша, и разработчикам, привыкшим работать с нормальными сайтами, где бизнес-логика занимает больше, чем "движок", всё эти проблемы кажутся какими-то мелкими.
Я вообще-то больше про принцип: сайт и движок - это разные штуковины. И про то, что они могут сидеть где угодно на диске. И про то, что движков может быть много, и любой сайт может обращаться к любому движку.
Как-то так...
Ну и я об этом же. Что такое возможно только в ситуации с фабрикой лендингов, когда сайтов миллион, и по большому счету все равно, на чем их лепить. Только это работает только в одну сторону — движок один, сайтов много. Сделать "много движков" не получится. Ну точнее получится, но в том смысле, в котором пишут все упоминатели фронденда — там да, обмен через джейсон, и какой бэкенд генерит этот джейсон совершенно без разницы.
Но вот на бэке — это какая-то блажь. Ну то есть понятно что можно иметь несколько ферм, одна держит 100 сайтов, вторая — два. Но это не то что люди понимают под словами "движков может быть много". Люди под этим в первую очередь понимают РАЗНЫЕ движки. Чего конечно, ни данная диковина, ни вообще никакой другой фреймворк не позволяет.
А ферме лендингов можно сделать на любом движке — это несложно. На той же Ларавели.
Выглядит так что для автора движок это nginx вместе с его Есть файловая система и алгоритмы формирования страниц по запрос а сайт это набор index.php, about_us.php и т.д. Ну лэндинги так и делают - бахнул хтмл и кайфуешь, не надо бэкапить никаких 20мб, только index.html.
Каникулы в школах начались, те кто сдавал информатику резко стали программистами
Мне кажется, что основная проблема автора в том, что он не понимает, как работают современные инструменты разработки, и, в частности — composer. И отсюда такие странные заявления про "бэкап в 500 мегабайт". То есть он реально не понимает, что как раз сайт на современном движке в занимает сам код (условные 0.5Мб) и один файлик composer.json на пару килобайт.
Также он не понимает, как на самом деле происходит интегрирование готовых движков в своё приложение. Для чего пишутся врапперы, которые либо наследуются от оригинальных классов движка, либо транслируют вызовы своего приложения в вызовы движка. А сам движок, как было сказано выше, подтягивается через композер. И в итоге, даже с использованием чужого движка, размер кода не превышает сотен килобайт. А не 20 бегамайт "без админки", которыми автор так гордится.
Ну и как вишенка на торте — при правильном подходе мы можем обновлять или заменять компоненты исходного движка, а при таком вот варварском — скачать, установить, и править в vendor — все зависимости оказываются прибиты гвоздями.
Есть вопросы как с ним работать. Документации 0. Есть дириктория demo с одним пустым index.php и
вот таким содержимым
require __DIR__ . '/../respond.php';
И всё.
Вопрос - почему в репозитории закомитана дириктория "vendor"?
Ссылка "Quickstart - You can download a ready-built package from the Downloads page on https://getlev.org/Lev" - не работает.
И если это отечественный продукт, почему столько зависимостей на зарубежные библиотеки - или искользуются symfony модули, в которые комитили исключительно россияне, а, скажем, там бразильцы разные и не дай то бог американцы не комитали ни строки?
Вы правы по большому счету во всем.
Сейчас проект Lev успешно прошел стадию проверки идеи, что сайт и движок могут быть физически разделены. Он полностью функционален, но нет документации, осталось много хвостов от его прародителя Grav. В частности, как вы заметили, в вендорах остался grav, который первое время реально был вендором, но по мере разработки архитектура изменилась радикально, grav уже давно не вендор, но пока его оставляем типа на всякий. Однозначно уберем. Но благодарны Grav останемся.
Насчет зарубежных библиотек — согласитесь, они не совсем зарубежные. Вы же сами пишете, что много российских комитов...
Я правильно думаю если скажу, что (определение) "коды сайта", которые упоминаются в этой статье, это (в общем понимании) и есть движок? Как отделить муку в хлебе, чтобы он при этом остался хлебом?.. Мда уж, я думаю здесь (автор в этой статье) фигнёй страдают
1 движок сайта для нескольких сайтов, только вот думаю, что никому этого не надо, поэтому и не делали так. Хотя...
Тот же ucoz (а интересно, он ещё жив?), другие подобные сайты с готовыми "блоками" из которых делаешь сайт, изобрести уже изобретённое...
Я так понимаю автор диплом пишет,скорее всего магистр или выше, потому что статьи в таком случае обязательны. Мне вот руководитель диплома говорил на МАГе, что обязательны 3 публикации, 1 из которых авторитетный источник который есть в списках ВАК (и в каком-то другом) , а остальные могут быть и просто интернетными ресурсами...
«коды сайта» - это коды бизнес-приложения сайта. Скажем, сайт магазина имеет приложение для управления товарами. Это и есть бизнес-приложение, причем именно сайта. К движку оно не имеет никакого отношения, поэтому живет оно на сайте.
Движок тоже имеет свое бизнес-приложение. Оно управляет всеми сайтами движка.
Мука отделена от хлеба. Страданий нет — все счастливы
На гитхабе ссылка https://getlev.org/Lev/downloads которая отвечает за скачивание не работает, спишем на хабра-эффект, да и папка demos пустовата.
Впрочем вообще не ясно что за движок без субд. Т.е. все движки изначально как раз и имели своей целью обвесить субд всем, чем только можно. Такое ощущение что вы воспринимаете роутинг — основной задачей движка. В таком случае у меня есть отличная альтернатива, это например php) тоже кстати движок не привязан к сайту) при чем совсем)
Идея с потоками конечно интересная, но хотелось бы по подробней.
Ну и возможность разделять увы весьма ограниченна. В идеале в движке есть код для всего, который нужно только настроить в красивой и удобной админке или в каких-то конфиг файлах типа json или php. И если желания простые, то так может даже битрикс с ucoz. Увы иногда надо что-то покодить, и тут вопрос степени зарывания в движок, нужно ли всего-то поменять фронт типа html js css, или нужно менять логику движка. Если первое — то все просто. Если второе, опять варианты, нужно ли просто менять логику готовых компонентов на уровне чуть изменить crudы или нужно ниже. Опять таки если нужно ниже, то это просто написать прямые запросы в базу или же нужно менять код ядра, или что еще хуже нужно писать свое ядро, похожее но отличающееся. Собственно последнее это то, что вы сделали с grav)) и то, что иногда будет приходится делать программистам.
Поэтому хочется узнать как ваш движок поддерживает эти уровни внесения изменений. Например:
- Возможно ли в нем создать интернет магазин, можно ли это сделать вообще не открывая код, ибо много где можно.
- Чем этот фреймворк приятней для создания лендингов чем голый php
- Как изменить логику стандартных компонентов, от простого в стиле "выполнить после вне кеша", до сложного "после строчки 1337 выполни вот этот код"
- Работы с базой нет, данные в файловой системе, которая по сути тоже база данных, в общем как они там хранятся? И соответственно как на них эвенты вешать, допустим есть финансовые операции и эвент на них точно должен происходить, поэтому его вынесли прямо в базу, тут нужно это через inotifywait делать?) Да и проверки информации в базе можно ли выносить выше php.
- Опять таки работы с базой нет, но информация хранится, всякие эвенты не забыты? И можно ли все же прикрутить базу, желательно с сохранением эвентов. А две базы и более? Типа postgre для данных, clickhouse для фильтрации и redis для кеша.
- Как с отложенным выполнением, т.е. я понимаю что для нормального это например rabbitMq, но насколько все работает без него?
Папка demos пустовата потому, что в ней определены всего 2 демо-страницы.
субд нет потому, что не нужна - в статье все сказано. Данные хранятся не в субд, а в конфиг-файлах.
Данные хранятся не в субд, а в конфиг-файлах.Как реализовано изменение этих данных (например регистрация нового пользователя)? Решена ли проблема состояния гонки при изменении конфига? Как делается запрос на поиск данных в конфиге (например, найти товар красного цвета и дешевле 1000 рублей)?
Автору эти вопросы задавать бесполезно. Надо понимать, что данное произведение — это такой BolgenOS. Взяли готовую установку Grav CMS, переклеили пару шильдиков и что-то подпилили под свои гениальные идеи.
Так что насчет файлов — это в Грав. А он, насколько я вижу, в свою очередь использует какое-то https://github.com/rockettheme/toolbox/tree/develop/File/src которое тоже не внушает никакого доверия.
Большинство конфигов неизменно в рамках одного запроса.
Пользователи хранятся в файлах конфигов, один конфиг на одного юзера. Эти файлы могут меняться в рамках запроса. Поиск в конфиге делается в классе User спец методами - простым перебором.
Если надо поменять остаток на складе для 1000 товаров, то надо 1000 раз открыть файл, полностью прочитать, поменять значение, записать файл.
Если надо найти товар по свойствам, то 5000 раз открыть файл, полностью прочитать, сравнить атрибуты. И никакой возможности ускорить поиск с помощью индексов.
А как будет работать на вашем движке форум с сотней тысяч топиков, в каждом из которых от сотни до пары тысяч комментариев?
Вот для этого и сгодится СУБД. Только она будет жить не в движке, а на сайте. Т.е. в приложении сайта. Кроме того, есть готовые плагины для многих пользователей.
А вот форум - это приложение со своей СУБД, его просто размещаем на сайте и все.
Как-то так...
Надо понимать, что как Грав, так и Лев не заточены под интернет-магазины (особенно под русскую реальность) и форумы.
И если малотоварный шоп на них с болью и страданиями сделать можно, то форумы - совсем не в тему, как и сошки
Как Грав, так и Лев не то что не заточены под какое-либо бизнес приложение, они не имеют даже СУБД. По той причине, что оба являются чисто движками, т.е. чисто обслуживают сайты (анализируют запрос браузера, формируют страницы, ...).
Магазины, форумы и любое иное бизнес приложение может быть размещено в сайте. При этом ключевой особенностью Лев является то, что его сайты отделены от движка, т.е. могут быть размещены где угодно на диске.
Что это за фетиш такой, "могут быть размещены где угодно на диске"? Какая от этого может быть практическая польза? Зачем это вообще упоминать?
Что такое "формируют страницы"? Как можно сформировать страницу, не зная, что на ней будет? Как "движок" может сформировать страницу без "сайта"? А если не может — то где оно, это разделение?
Сайты Lev могут размещаться где угодно на диске, а не только в директории движка. И это основное достоинство архитектуры Lev.
Как "движок" может сформировать страницу без "сайта"? - согласен с вами, никак. Поэтому движок Lev формирует страницу сайта обращаясь к настройкам страниц самого сайта.
В чем заключается это достоинство? Что даёт размещение "где угодно на диске"? Какую проблему решает?
проблема указана в начале пассажа: "где угодно на диске, а не только в директории движка"... В современных фреймворках сайты могут размещаться только в спец-директории самого движка. Это есть ограничение, согласитесь.
Во-первых, это даже не ограничение, не говоря уже о "проблеме". Это какая-то высосанная из пальца блажь. Сотни тысяч разработчиков во всем мире используют десятки фреймворков, и ни один из них не заметил этого "ограничения" (которое, кстати, элементарно обходится при желании).
Но самое главное — называть это "основным достоинством архитектуры" — это совсем уже маразм. Вот вы это сейчас серьёзно? Главное, чем может похвастаться ваш фреймворк — это отдельная папочка для файликов? По-вашему, архитектура — это где файлики лежат?
ссылка https://getlev.org/Lev/downloads которая отвечает за скачивание не работает - да, не работает, не реализовано, но мы над этим работаем...
А вы умеете разжечь любопытство. Сначала непонятная статья. Потом непонятные, окончательно запутывающие комментарии. А потом, когда я все же собрался на сайт и глянуть код оказалось что сайт недоступен, а скачивания нет, не реализовано. Ну что код почему то не на гитхабе, ладно, спишем на обстановку. И я процентов на 97 уверен что тут речь про очередной очень странный велосипед с привкусом болгенос под соусами "инновации" , "отечественное" , "у меня будет крутой диплом" . Сам такое любил в своё время, ну та часть которая касается диплома. Правда не так помпезно. Но все же есть маленький шанс что там что-то интересное. Да и любопытно что все таки имел ввиду автор под понятными только ему терминами и идеями. Короче лично я жду когда можно скачать и посмотреть. Статья провалена, а вот возбудить любопытство удалось.
в статье есть ссылки на гитхаб: https://github.com/getlev/lev
Ну а если без сарказма и стеба, по статье и комментариям я вижу недостаток опыта и слабое понимание области веб разработки. Это нормально, ни один разработчик не стал синьором не побывав джуном. По ним же я вижу горящие глаза и в целом адекватность, автор не срывается на грубость и отвечает, поясняет как может, это отлично, хороший настрой.
Написать свой фреймворк или CMS - ну через это проходили если не все то очень многие, это нормально, обычный период когда уже чувствуешь что что-то знаешь и можешь и появляются идеи сделать что-то крутое, но при этом еще не понимаешь как мало знаешь для серьезного проекта, это тоже в принципе хорошо. Правда за одним исключением, когда человек в упор не хочет слушать, замыкается, не понимает почему общество его гениальные идеи зарывает в море юмора и стеба, иногда люди так бросали разработку совсем, тогда это плохо. Я не знаю есть ли у вас эти симптомы или нет.
Хотите совет? Вместо статьи рекламы, напишите статью презентацию. Расскажите что вы делаете, для чего, какие идеи применили, что от них ожидаете. И спросите совета, не надо пытаться устроить шоу "мы сейчас перевернем ваше представление о разработке и поведем за собой в будущее", от этого вы получите только море стеба, потому что не перевернете, не поведете, но выставите себе довольно глупо. Напишите статью с фокусом на получение фидбека, советов, дайте пощупать код, может даже устройте из этого опенсорс и кто-то опытный подключится к вам в качестве ментора или даже контрибьютора. Ваши идеи вполне могут быть интересными, но идеи надо еще реализовать, и главное понять для чего и как, а тут пригодится опыт. Многие разработчики вполне непротив проревьювить очередной велосипед и дать советы, указать на ошибки, сказать куда покопать и где есть проблемы как с идеями так и с кодом и даже просто где серьезные пробелы в понимании области и взятой задачи, но только если люди готовы слушать. Короче не пытайтесь "продать", а демонстрируйте и спрашивайте совета. Стеб по прежнему будет, всегда есть люди которых хлебом не корми а дай постебаться над новичками которые взялись за амбициозную задачу, но в отличие от этой статьи он будет только от таких вот людей, которые вам не нужны и там просто игнор, а вот другие думаю ответят и помогут. Не помогут - пишите мне в личку, менторство и тем более контрибьютинг не обещаю, но как минимум провалидирую идеи и укажу на проблемы если есть. Но только если вы реально делаете что-то новое, и делаете это потому что есть идеи и их хочется реализовать, потому что вам интересно или для обучения/развития. Если вы очередной Денис Попов, с копипастой под другим именем и стремлением к славе ради славы и почесывания ЧСВ - тогда мимо.
Благодарю за советы. Хотел бы обсудить с вами. Попытался пойти в вашу личку https://habr.com/ru/conversations/1tiger1/ - но там все серое типа заблокировано...
Я вижу так: в сайтостроении есть два основных объекта — сайт и движок. Они совершенно разные.
Базовая схема их взаимодействия такая:
Сайт получает запрос браузера на страницу. Он обращается к движку с просьбой о помощи. Движок анализирует запрос браузера на предмет какая страница запрошена, формирует контент страницы обращаясь к настройкам сайта и возвращает готовую страницу браузеру.
То бишь всю работу производит движок.
А что же делает сайт? А сайт занят бизнес-логикой и настройками (определениями) страниц. Сайт не формирует страницы, он их только определяет.
Если есть два основных объекта «сайт» и «движок», то, по идее должны быть два основных класса, которые определяют свойства и методы этих объектов.
Так вот, я знаю, что в топовых фреймворках нет своего класса для сайта, а во многих нет даже класса для движка. Почему нет? Потому, что свойства этих классов сидят в конфигах, а их методы разбросаны по всему фреймворку. Это плохая архитектура.
Далее. Я взял неплохой фреймворк Grav. Он, как и большинство фреймворков, поддерживает квази-мультисайт, это когда все мультисайты сидят в некоем спец дире самого фреймворка. И попытался для него полностью отделить сайт от движка. Это получилось - движок в своем дире, сайт - в своем где угодно на диске. Правда, пришлось существенно перелопатить движок.
Как-то так. Хотелось бы обсудить тему с вами детальнее...
Это очень смешное заблуждение.
Во-первых, во всех фреймворках "сайт" полностью отделён от "движка".
"Движок" лежит в папке src, сайт — в папке app, в которой и пишутся контроллеры, модели, репозитории, сервисы шаблоны и так далее. Плюс папка config, в которой пишется то, что не требует кода, а только настроек, например роутинг.
Во-вторых, никаких "классов", в терминах синтаксиса РНР, ни для сайта ни для движка быть не должно. У движка класс есть только в самых отсталых фреймворках, типа Yii2. В нормальных фреймворках такого мусора нету, есть только отдельные классы, каждый для своей задачи. Класс "сайт" нормальным сайтам тоже не нужен, а может пригодиться только для случая, который я описывал выше — фабрика лендингов. Но в этом случае такой класс не будет представлять из себя ничего особенного — просто обычный контроллер, который выдает не одну какую-то страницу, а поддерживает мультисайтовость.
Отписался вам с моим контактом.
Я не знаком с grav, вот сейчас всколзь глянул документацию, выглядит как cms для в основном статического контента, плюс минимальная поддержка форм (в плане с минимум логики, на уровне отправить email или что-то простое сделать). И все это максимально заточено на простоту, но все в рамках статики. То есть лендинги и аналогичные задачи. И тут есть несколько моментов где мне кажется вы путаетесь:
Grav не фреймворк, он CMS, его задача, как у всех CSM это управление контентом. Дополнительно к этому у него очень узкая ниша возможностей, и сделано это специально, чтобы сохранить простоту и низкий порог входа. В жертву принесена гибкость и все задачи которые выходят за пределы статики и страниц. Даже возможность отделения фронтенда в виде js приложения (могу ошибаться) принесена в жертву. То есть это узкий инструмент для специфической задачи, с фокусом на простоту, минимальный порог входа и удобство в рамках этой узкой задачи. Это неплохо, но учитывать нужно. Веб разработка не ограничивается статикой, надеюсь вы это понимаете. В ввиду всего этого, попытки сравнить Grav и сложные универсальные фреймворки довольно бесмысленно. У них просто разные задачи и разные требования, а следовательно и разные подходы. Вы уж простите сравниваете игровой руль с машиной, само собой там разные фокусы. Среди проектов в которых я участвовал, например, много таких где в принципе нет "сайта", или он есть но где-то там, как отдельный сервис, для взаимодействия с пользователем, а львиная доля работы происходит на бэкэнде "под капотом". Я не знаю какую задачу вы себе поставили, поэтому не могу дать конкретных советов сейчас по ней. Поэтому пока только эти:
Не судите по одной узкой области о подходах для всей области, это бесмысленно.
вы, если базировались на Grav сделали не фреймворк а CMS, это разные вещи, иногда CMS включают в себя фреймворк и могут быть довольно сложными в плане возможностей функционала, но все равно нет, да и это совсем не тот случай.
Разберитесь что вы делаете и для каких задач, без этого вряд ли что-то получится.
Мультисайты - не знаю, по моему очень спецфическая, мало кому нужная (в рамках задач Grav) вещь, могу ошибаться. Если говорить о фронтендах то сейчас более востребованы, ну назовем это "мультиприложения", возможность удобно к одному бэкенду присоединить фронт в браузере, мобильное приложение, да хоть кнопку IOT или колонку от амазона. Это да, особенно в продажах и разных услугах, а несколько сайтов - редко. так что особо не ожидайте многого от этой фичи.
Без понятия чего вы так зацепились за терминологию сайт и движок и пытаетесь их разделить. Это на самом деле старая история и тут проблема терминологии. Кто занимается роутингом и другими рутинными задачами, где бизнес логика, как это все взаимодействует. Старая уровня "серверов приложений" на java и попыток от apache притащить это в php, лет 20-25 ей. Сейчас таким не страдают, если что-то и делится то аспектно, по сервисам.
Директории, диски, сервера - сейчас мало кого заботят эти вопросы. откройте для себя Docker, если еще не сделали этого, посмотрите в общих чертах AWS, kubernetus и прочую облачность и оркестрацию, и поймете что делят сейчас код по задачам и аспектам, а технически это происходит в контейнерах, которые общаются между собой. И в связи с этим фича какого-либо разделения на диске, в сложных приложениях никого не заботит, а в обычной статике уровня лендинга - ну тоже в принципе. Лэндинг в большинстве случаев это вещь которую поставил и забыл, в админку иногда залез поправить контент, все. какая разница что там на сервере.
Посмотрите и пощупайте какой нибудь взрослый фреймворк типа Symfony (мой любимый) или Laravell (популярен не менее, но все же на мой взгляд не такой удобный, хотя люди долго писавшие на js должны оценить), это даст перспективу.
не забывайте что лендинги потихоньку умирают, их делают, но скорее потому что положено, их функцию давно на себя перетащили страницы в соцсетях, каналы в мессенжерах/youtube/тиктоке и прочие места где уже есть аудитория.
Очень надеюсь я своим "это все узкая область" и "простой функционал" не погасил горящие глаза, это не было целью. Продолжайте, или переключайтесь на другой пет-проджект, но в любом случае вам нужно понимать что вы делаете, для кого и каких задач, и терминологию, иначе очень сложно будет обьяснить вашим потенциальным пользователям что это и для каких задач. За остальным, если мое сообщение в личку пришло, пишите в телеграм, посмотрю код если дадите, скажу какие решения хорошие а где проблемы, а где вы слишком фокусируетесь на мелочах. Но сразу скажу, лендинги не моя область (хоть в них нет и ничего сложного, но все же я их почти не делал, а значит представляю потребности в общих чертах), фронт не моя область. Cложная бэкенд логика, сервисы, интеграция, апи - моя область. так что советы будут скорее из общих знаний чем из специфических, не ждите от меня хороших советов формата "как сделать хорошую CMS для лендингов".
выглядит как cms для в основном статического контента
Вывод ошибочен, это все же Symfony (+Twig) под капотом, так что динамики даже на этом можно получить
Даже возможность отделения фронтенда в виде js приложения (могу ошибаться) принесена в жертву.
Да, тут есть принципиальная ошибка: Grav никоим образом не лимитирует возможные фронты, более того - в нем из коробки есть возможность отдавать данные в любом формате, это вопрос только использованного шаблона (если кратко и конспективно), так что под headless CMS c нужным фронтом он приспосабливается (другое дело, что спрос именно на такую пару не очень велик и вообще, и в России)
Надо не "работать над этим", а банально зарегистрировать домен getlev.org и повесить живой сайт на lev на это имя до, а не "когда-нибудь потом"
Мультисайтовость в оригинальном Grav вполне прилично работает, аж 2 разными методами без грязных хаков, хоть и с известными ограничениями, а других причин для Lev не озвучено.
Возьмите nuxt.js и у вас будет полностью независимый фронт. Дальше через rest его можно связать с любым бекендом.
По бекапам. Сейчас стоит бекапить только бд, и папку uploads. Все остальное поднимается из гита за 15 мин.
Не совсем понял чем это «разделение сайта от движка» лучше использования «тупого фронтэнда» (Next, Nuxt …) и умного бэкэнда (REST/GraphQL API сервера) ?
Не знаю, как сейчас в Yii или Laravel, но в Symfony ORM по умолчанию не идет, ее нужно подключать отдельно. Если БД не нужна, то и пакет не подключаешь;
Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах (если я правильно понял). Или для вас СУБД - это только реляционные СУБД?
"Мультисайтовость" можно делать и на Symfony: выносишь vendor в отдельное место, весь кастомный код для каждого отдельного сайта натравливаешь на этот единый для всех vendor. Только зачем, если удобнее держать независимые версии vendor для каждого сайта? Вам жалко несколько десятков мегабайт?
Как будто конфиги в yaml - это что-то уникальное для Lev. В Symfony они уже давно, и во многих случаях от них сейчас отказываются в пользу PHP/Annotations по ряду причин.
"Вы говорите, что СУБД не нужна, но сами реализуете свою собственную СУБД, работающую на файлах..." - я говорю, что СУБД не нужна для реализации основных функций движка. Я не могу говорить, что СУБД не нужна вообще нигде и никогда. Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
"Как будто конфиги в yaml - это что-то уникальное для Lev" - вы правы, я как-то не очень аккуратно выразился...
Lev не реализует свою СУБД, для поиска или перебора файлов Lev пользует обычные функции файловой системы.
Вы организуете хранение данных в файлах, это тоже БД, просто не классическая реляционная, типа MySQL или Postgres. А если есть БД, то есть и СУБД. Модули чтения и записи в файлы, даже если они используют обычные функции файловой системы - это и есть ваша самописная СУБД.
Прочтите определение термина "База данных" хотя бы на той же Википедии:
Ба́за да́нных — совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных[1][2][3].
У вас есть данные, есть схема (без схемы вы не знали бы, как данными можно манипулировать), есть манипулирование данными.
Систе́ма управле́ния ба́зами да́нных, сокр. СУБД (англ. Database Management System, сокр. DBMS) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных[1].
У вас есть технические средства для использования баз данных - пресловутые fread/fwrite.
Еще раз: СУБД - это не только РСУБД.
И, в конце концов, классические БД - это те же fread/fwrite под капотом.
Ну и вишенка — у топовых фреймворков, с которыми я знаком (WP, Laravel, Symphony, Drupal, Yii2) вообще нет объекта (класса) Site! Как вам такое?
Это прекрасно.
Особенно прекрасно, когда под термин «фреймворк» запихивают CMS системы. До этой строчки уже начал сомневаться в достаточной компетенции автора в веб-разработке, но это меня добило.
Все же дочитал до конца статью и становится понятно, что автор решил лишь пропиарить свой продукт, который ничем не лучше того что он перечислил выше. И даже хуже.
Я так и не понял зачем мне этот «фреймворк» и для каких проектов мне его использовать даже после перечисленных якобы «преимуществ» перед другими фреймворками. Может быть в статье стоило более детально раскрыть весь потенциал вашего продукта?
Автор, подскажите пожалуйста, сколько времени вы потратили на разработку данного продукта? Есть ли какие-либо успешные коммерческие проекты созданные с помощью данного «фреймворка»?
Левитация — а не отделить ли нам сайт от движка?