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
Комментарии (30)
m03r
23.06.2022 08:01+7Статья прямо как телемагазин: сначала обозначает проблему, затем драматизирует её до предела («Движок в сто раз больше полезной нагрузки!»), а затем предлагает блестящее решение — без подробностей, замеров производительности и прочих обоснований. Честно говоря, к концу я перестал понимать, что автор называет сайт, а что — движок и какую проблему вообще решает. Но и это ещё не всё: зачем
vendorсо всеми пакетами лежит в репозитории?
FanatPHP
23.06.2022 08:29+1Ахаха, я понял. Это же импортозамещение. После того как я почитал ридми на русском, то, честно говоря, думал что Грав там будет в в зависимостях. Но тут всё гораздо смешнее: берём Grav Framework, устанавливаем, и начинаем хачить свой левиафан — или как его там — прямо по живому. Так в 90-е игры русифицировали. То есть по своей сути — это инсталляция Grav Framework в которой что-то допилили руками. Жаль, у меня страница загрузки не открывается, но я на 100% уверен, что там никакого композера и никакого даже гит клона — только зип архив, только хардкор!
svratenkov Автор
24.06.2022 07:23-1В чем-то вы правы. Первое время Grav был вендором Lev. Затем решили от этого отказаться. Grav сейчас не вендор, а предшественник. Из вендоров уберем.
FanatPHP
23.06.2022 08:20+4"Есть и достижение — первый российский (и мировой?) фреймворк Levitation с новой архитектурой"… который "является расширением Grav, причем небольшим".
Когда видишь такое трескучее начало — уже на автомате ищешь мелкий шрифт. И что характерно — находишь.
Aleks_ja
23.06.2022 11:23"Движок" в соседней дириктории - это понятно. А что имеется в виду "движок" на другом сервере, и как это организовывается?
svratenkov Автор
24.06.2022 07:43-2Сервера имеют имена, в Винде буковки с:/, d:/, … Вам лучше обратиться к своему саппорту.
Aleks_ja
24.06.2022 09:26А на Линуксе какие буковки у разных серверов?
Простите, у меня Ubuntu, и сапорта своего нету, приходится во всём разбираться самому.
1Tiger1
23.06.2022 12:30+1А с обоями как, не скучные?
Честно прочитал всю статью, так и не понял что автор называет движком, что сайтом и мкльтисайтом, почему это магазины вдруг стали все бигдатой, и для каких областей вообще этот фреймворк. Стоило бы начать с этого, а не с бесконечного повторения про бэкапы, мультисайты и передовые отечественные разработки. Вы же на техническом ресурсе вроде-бы, а не на региональном телеканале рассказываете про болгенос и чудо флешку-маркер. Не надо изобретать термины, но если реально надо то дайте им четкое и понятное определение. Сайт это фронтенд? Движок это система кэширования страниц? Фраза про отсутствие класса Site на популярных фреймворках вообще убила. Очень уж помпезно построена. Звучит как "каждый более менее уважающий себя фреймворк должен иметь класс Site". А он нужен? Для чего? И вот так со всем в статье, какие-то непонятные мотивы и задачи, понятная одному только автору терминология, надуманные проблемы и их героическое решение.
svratenkov Автор
24.06.2022 08:13-2Сайт — это фронтенд, движок — это не только система кэширования, а весь бэкенд.
Класс Site нужен для инкапсуляции всех свойств и методов объекта сайт. Объект Site есть на экране браузера, но его почему-то нет в фреймворках. В нынешних фреймворках свойства и методы сайта распылены по разным конфигам и классам. Это результат (вполне естественный) первого этапа развития сайтостроения, когда отрабатывались подходы к управлению одним сайтом. Вроде отработали...
Проект Lev говорит простые вещи: сайт есть самостоятельная сущность, сайт и движок — разные сущности. Давайте это осознаем и разделим их. Как то так...
Aleks_ja
24.06.2022 11:36+2Я вам скажу прямо - у вас низкий уровень понимания технологий и вы слабо разбираетесь в теме программирования (как минимум web), однако, наверняка считаете, что вы серьёзный программист и написали что-то грандиозное. Вам предстоит ещё долгий путь познания.
Даже сама терминология, которой вы пользуетесь - неправильная. Например, тут можете прочитать что такое фронтенд, что такое бэкенд.
1Tiger1
26.06.2022 03:27То есть вы разделили бэк и фронт? Так их уже давно разделяют, если есть потребность. Про класс site все ещё не понял, вы засунули весь фронтенд в один класс?
motoroller95
23.06.2022 12:57+1Выглядит так что для автора движок это nginx вместе с его
Есть файловая система и алгоритмы формирования страниц по запроса сайт это набор index.php, about_us.php и т.д. Ну лэндинги так и делают - бахнул хтмл и кайфуешь, не надо бэкапить никаких 20мб, только index.html.Каникулы в школах начались, те кто сдавал информатику резко стали программистами
FanatPHP
23.06.2022 13:22+2Мне кажется, что основная проблема автора в том, что он не понимает, как работают современные инструменты разработки, и, в частности — composer. И отсюда такие странные заявления про "бэкап в 500 мегабайт". То есть он реально не понимает, что как раз сайт на современном движке в занимает сам код (условные 0.5Мб) и один файлик composer.json на пару килобайт.
Также он не понимает, как на самом деле происходит интегрирование готовых движков в своё приложение. Для чего пишутся врапперы, которые либо наследуются от оригинальных классов движка, либо транслируют вызовы своего приложения в вызовы движка. А сам движок, как было сказано выше, подтягивается через композер. И в итоге, даже с использованием чужого движка, размер кода не превышает сотен килобайт. А не 20 бегамайт "без админки", которыми автор так гордится.
Ну и как вишенка на торте — при правильном подходе мы можем обновлять или заменять компоненты исходного движка, а при таком вот варварском — скачать, установить, и править в vendor — все зависимости оказываются прибиты гвоздями.
Aleks_ja
23.06.2022 14:15Есть вопросы как с ним работать. Документации 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 модули, в которые комитили исключительно россияне, а, скажем, там бразильцы разные и не дай то бог американцы не комитали ни строки?
svratenkov Автор
24.06.2022 08:36-2Вы правы по большому счету во всем.
Сейчас проект Lev успешно прошел стадию проверки идеи, что сайт и движок могут быть физически разделены. Он полностью функционален, но нет документации, осталось много хвостов от его прародителя Grav. В частности, как вы заметили, в вендорах остался grav, который первое время реально был вендором, но по мере разработки архитектура изменилась радикально, grav уже давно не вендор, но пока его оставляем типа на всякий. Однозначно уберем. Но благодарны Grav останемся.
Насчет зарубежных библиотек — согласитесь, они не совсем зарубежные. Вы же сами пишете, что много российских комитов...
Kuprijan
23.06.2022 20:26Я правильно думаю если скажу, что (определение) "коды сайта", которые упоминаются в этой статье, это (в общем понимании) и есть движок? Как отделить муку в хлебе, чтобы он при этом остался хлебом?.. Мда уж, я думаю здесь (автор в этой статье) фигнёй страдают
1 движок сайта для нескольких сайтов, только вот думаю, что никому этого не надо, поэтому и не делали так. Хотя...
Тот же ucoz (а интересно, он ещё жив?), другие подобные сайты с готовыми "блоками" из которых делаешь сайт, изобрести уже изобретённое...
Я так понимаю автор диплом пишет,скорее всего магистр или выше, потому что статьи в таком случае обязательны. Мне вот руководитель диплома говорил на МАГе, что обязательны 3 публикации, 1 из которых авторитетный источник который есть в списках ВАК (и в каком-то другом) , а остальные могут быть и просто интернетными ресурсами...
svratenkov Автор
24.06.2022 08:46«коды сайта» - это коды бизнес-приложения сайта. Скажем, сайт магазина имеет приложение для управления товарами. Это и есть бизнес-приложение, причем именно сайта. К движку оно не имеет никакого отношения, поэтому живет оно на сайте.
Движок тоже имеет свое бизнес-приложение. Оно управляет всеми сайтами движка.
Мука отделена от хлеба. Страданий нет — все счастливы
MKMatriX
24.06.2022 12:19На гитхабе ссылка https://getlev.org/Lev/downloads которая отвечает за скачивание не работает, спишем на хабра-эффект, да и папка demos пустовата.
Впрочем вообще не ясно что за движок без субд. Т.е. все движки изначально как раз и имели своей целью обвесить субд всем, чем только можно. Такое ощущение что вы воспринимаете роутинг — основной задачей движка. В таком случае у меня есть отличная альтернатива, это например php) тоже кстати движок не привязан к сайту) при чем совсем)
Идея с потоками конечно интересная, но хотелось бы по подробней.
Ну и возможность разделять увы весьма ограниченна. В идеале в движке есть код для всего, который нужно только настроить в красивой и удобной админке или в каких-то конфиг файлах типа json или php. И если желания простые, то так может даже битрикс с ucoz. Увы иногда надо что-то покодить, и тут вопрос степени зарывания в движок, нужно ли всего-то поменять фронт типа html js css, или нужно менять логику движка. Если первое — то все просто. Если второе, опять варианты, нужно ли просто менять логику готовых компонентов на уровне чуть изменить crudы или нужно ниже. Опять таки если нужно ниже, то это просто написать прямые запросы в базу или же нужно менять код ядра, или что еще хуже нужно писать свое ядро, похожее но отличающееся. Собственно последнее это то, что вы сделали с grav)) и то, что иногда будет приходится делать программистам.
Поэтому хочется узнать как ваш движок поддерживает эти уровни внесения изменений. Например:
- Возможно ли в нем создать интернет магазин, можно ли это сделать вообще не открывая код, ибо много где можно.
- Чем этот фреймворк приятней для создания лендингов чем голый php
- Как изменить логику стандартных компонентов, от простого в стиле "выполнить после вне кеша", до сложного "после строчки 1337 выполни вот этот код"
- Работы с базой нет, данные в файловой системе, которая по сути тоже база данных, в общем как они там хранятся? И соответственно как на них эвенты вешать, допустим есть финансовые операции и эвент на них точно должен происходить, поэтому его вынесли прямо в базу, тут нужно это через inotifywait делать?) Да и проверки информации в базе можно ли выносить выше php.
- Опять таки работы с базой нет, но информация хранится, всякие эвенты не забыты? И можно ли все же прикрутить базу, желательно с сохранением эвентов. А две базы и более? Типа postgre для данных, clickhouse для фильтрации и redis для кеша.
- Как с отложенным выполнением, т.е. я понимаю что для нормального это например rabbitMq, но насколько все работает без него?
svratenkov Автор
24.06.2022 12:47Папка demos пустовата потому, что в ней определены всего 2 демо-страницы.
субд нет потому, что не нужна - в статье все сказано. Данные хранятся не в субд, а в конфиг-файлах.
Rsa97
24.06.2022 14:02+1Данные хранятся не в субд, а в конфиг-файлах.
Как реализовано изменение этих данных (например регистрация нового пользователя)? Решена ли проблема состояния гонки при изменении конфига? Как делается запрос на поиск данных в конфиге (например, найти товар красного цвета и дешевле 1000 рублей)?FanatPHP
24.06.2022 14:42Автору эти вопросы задавать бесполезно. Надо понимать, что данное произведение — это такой BolgenOS. Взяли готовую установку Grav CMS, переклеили пару шильдиков и что-то подпилили под свои гениальные идеи.
Так что насчет файлов — это в Грав. А он, насколько я вижу, в свою очередь использует какое-то https://github.com/rockettheme/toolbox/tree/develop/File/src которое тоже не внушает никакого доверия.
svratenkov Автор
24.06.2022 15:06Большинство конфигов неизменно в рамках одного запроса.
Пользователи хранятся в файлах конфигов, один конфиг на одного юзера. Эти файлы могут меняться в рамках запроса. Поиск в конфиге делается в классе User спец методами - простым перебором.
Rsa97
24.06.2022 17:39То есть, 5000 пользователей — 5000 файлов с конфигом.
Если надо поменять остаток на складе для 1000 товаров, то надо 1000 раз открыть файл, полностью прочитать, поменять значение, записать файл.
Если надо найти товар по свойствам, то 5000 раз открыть файл, полностью прочитать, сравнить атрибуты. И никакой возможности ускорить поиск с помощью индексов.
А как будет работать на вашем движке форум с сотней тысяч топиков, в каждом из которых от сотни до пары тысяч комментариев?svratenkov Автор
25.06.2022 14:06Вот для этого и сгодится СУБД. Только она будет жить не в движке, а на сайте. Т.е. в приложении сайта. Кроме того, есть готовые плагины для многих пользователей.
А вот форум - это приложение со своей СУБД, его просто размещаем на сайте и все.
Как-то так...
svratenkov Автор
24.06.2022 12:52ссылка https://getlev.org/Lev/downloads которая отвечает за скачивание не работает - да, не работает, не реализовано, но мы над этим работаем...
1Tiger1
26.06.2022 03:44А вы умеете разжечь любопытство. Сначала непонятная статья. Потом непонятные, окончательно запутывающие комментарии. А потом, когда я все же собрался на сайт и глянуть код оказалось что сайт недоступен, а скачивания нет, не реализовано. Ну что код почему то не на гитхабе, ладно, спишем на обстановку. И я процентов на 97 уверен что тут речь про очередной очень странный велосипед с привкусом болгенос под соусами "инновации" , "отечественное" , "у меня будет крутой диплом" . Сам такое любил в своё время, ну та часть которая касается диплома. Правда не так помпезно. Но все же есть маленький шанс что там что-то интересное. Да и любопытно что все таки имел ввиду автор под понятными только ему терминами и идеями. Короче лично я жду когда можно скачать и посмотреть. Статья провалена, а вот возбудить любопытство удалось.
1Tiger1
26.06.2022 04:21Ну а если без сарказма и стеба, по статье и комментариям я вижу недостаток опыта и слабое понимание области веб разработки. Это нормально, ни один разработчик не стал синьором не побывав джуном. По ним же я вижу горящие глаза и в целом адекватность, автор не срывается на грубость и отвечает, поясняет как может, это отлично, хороший настрой.
Написать свой фреймворк или CMS - ну через это проходили если не все то очень многие, это нормально, обычный период когда уже чувствуешь что что-то знаешь и можешь и появляются идеи сделать что-то крутое, но при этом еще не понимаешь как мало знаешь для серьезного проекта, это тоже в принципе хорошо. Правда за одним исключением, когда человек в упор не хочет слушать, замыкается, не понимает почему общество его гениальные идеи зарывает в море юмора и стеба, иногда люди так бросали разработку совсем, тогда это плохо. Я не знаю есть ли у вас эти симптомы или нет.Хотите совет? Вместо статьи рекламы, напишите статью презентацию. Расскажите что вы делаете, для чего, какие идеи применили, что от них ожидаете. И спросите совета, не надо пытаться устроить шоу "мы сейчас перевернем ваше представление о разработке и поведем за собой в будущее", от этого вы получите только море стеба, потому что не перевернете, не поведете, но выставите себе довольно глупо. Напишите статью с фокусом на получение фидбека, советов, дайте пощупать код, может даже устройте из этого опенсорс и кто-то опытный подключится к вам в качестве ментора или даже контрибьютора. Ваши идеи вполне могут быть интересными, но идеи надо еще реализовать, и главное понять для чего и как, а тут пригодится опыт. Многие разработчики вполне непротив проревьювить очередной велосипед и дать советы, указать на ошибки, сказать куда покопать и где есть проблемы как с идеями так и с кодом и даже просто где серьезные пробелы в понимании области и взятой задачи, но только если люди готовы слушать. Короче не пытайтесь "продать", а демонстрируйте и спрашивайте совета. Стеб по прежнему будет, всегда есть люди которых хлебом не корми а дай постебаться над новичками которые взялись за амбициозную задачу, но в отличие от этой статьи он будет только от таких вот людей, которые вам не нужны и там просто игнор, а вот другие думаю ответят и помогут. Не помогут - пишите мне в личку, менторство и тем более контрибьютинг не обещаю, но как минимум провалидирую идеи и укажу на проблемы если есть. Но только если вы реально делаете что-то новое, и делаете это потому что есть идеи и их хочется реализовать, потому что вам интересно или для обучения/развития. Если вы очередной Денис Попов, с копипастой под другим именем и стремлением к славе ради славы и почесывания ЧСВ - тогда мимо.
des1roer
Если нужен headless cms - смотреть в сторону lumen. А так непонятно зачем использовать фреймворк на который не найдешь разрабов. И дружественный YAML конфиг - он не дружественный. В последних версиях symfony это поняли сейчас конфиг - php файлы