А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.
Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.
При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.
Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!
Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
github.com/modxcms/revolution/pull/13900#issuecomment-390403195
Собственно, с тех пор я как-то и перестал спорить. Тут люди десятилетиями работают, им виднее.
Только политоты накинуть на вентилятор, молодец.
Любители фронтенда сами подтянутся, когда им будет куда отправлять запросы для получения данных.
Можно долго обсуждать и принимать решения, но пока у проекта не появится паровозик, который его потащит — проект никуда и не поедет.
На данный момент, насколько я понимаю, никакая ORM вообще не нужна, потому что мы будем работать с готовыми объектами и процессорами MODX, делая к ним запросы, получая ответ, обрабатывая и отдавая в чистом виде наружу.
RestApi — это просто слой абстракции над ядром MODX со всеми его сущностями.
Объекты MODX работают через xPDO, никуда от него не денешься. Не писать же сразу все свои modResource, modDocument и т.д. с их логикой — это уже точно не поднять.
А если серьёзно — такой подход ничем никого не обязывает и ни к чему не привязывает. Учитывая, как обстоят дела с финансированием и свободным временем у разработчиков — это единственный, на мой взгляд, реальный вариант хоть что-то сделать.
Выкинуть MODX никогда не поздно, но не нужно это делать в самом начале.
Если работать с тем, что есть — у нас опять будут разные костыли, потому что нынешние процессоры завязаны на нынешнюю админку и от этого нужно избавиться. Плюс, автоматическая генерация документации будет возможна только по новому API.
А вот как появится такое API (хотя-бы для работы хоть с чем-то простым), тогда можно начинать и фронтенд. Дальше обновляется API и за ним идёт админка.
В моём представлении — вот так.
Нужно 2 дополнения для MODX:
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.
Я уже делал что-то подобное для своего мобильного приложения, хоть это и не Rest. Можно посмотреть, ради интереса, только не берите за основу.
Внимание, сам RestApi не обязательно писать на MODX, он должен просто работать с MODX, но базироваться может хоть на Slim3 + Eloquent, если разработчикам так удобнее.
— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
С самого начала нужно писать тесты и документировать API (это можно делать и автоматически). Тогда это не просто взлетит, а придаст второе дыхание системе. Любители React.js смогут написать свою админку — Api-то общий и понятный.
При таком подходе, над дополнениями могут работать 2 независимых команды. Кому-то по душе бэкенд, кому-то фронтенд.
Дальше очередь за дополнениями. Некоторые будут работать со старой админкой, некоторые — с новыми, это уже на совести их авторов. Пусть победит сильнейший!
Ну а в очень дальнем будущем, RestApi можно будет и вовсе отвязать от MODX и использовать с каким-то другим ядром. Потому что это Api является уровнем абстракции, под которым можно заменить что угодно — и фронтенд об этом не узнает.
И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
По сути, админка — это просто специальный раздел сайта, который требует особых прав. Юзер логинится на сайт и может работать в этом разделе, всё выглядит одинаково.
Проекты серьёзные, так что всё это делается под заказ.
Честно говоря, сейчас всё идеально работает, даже не знаю, что мне эдакого сможет родной Lumen предложить.
Ну и звёздочек у Slim на Github больше — а все знают, что это самое важное!
Самому еще эти детские капризы не надоели? Или делись знаниями, и имей в виду, что не всем они могут даваться легко, или молчи уже тогда в тряпочку. А то как девица ветреная себя ведёшь, смотреть противно.
Хотелось дать им возможность самим писать заметки, но оказалось, что это никому не нужно.
Возможно, западные коллеги когда-нибудь тоже придут к мысли, что лучше писать всё в одном месте, нежели растаскивать информацию по мелким личным бложикам. Ну а пока нет — пусть читают нас.
Sphinx — это отдельно крутящий демон, которому ты отдаёшь поисковый запрос и он делает всю работу. Включая, например, подсветку найденных слов.
Выглядит это примерно как SQL запрос, только не в БД, а в Sphinx
В mSearch2 же это всё делается вручную, используя формы слов от phpMorphy. Наверное можно просклонять слова в phpMorphy, потом поискать их в Sphinx, потом отдельно отранжировать и соединить ответы — но вряд ли это что-то улучшит, а вот усложнит — наверняка.
Я такого не нашёл. Есть только pymorphy2, но он на Python и его ни разу не использовал.
Как буду готов — начну писать заметки про это дело, когда сам освою как следует.
Потому что это полностью готовый отрендеренный фронтенд, который не нужно больше обрабатывать на сервере вообще.
Вот подробности — ru.nuxtjs.org/guide (возможно, понадобится включить VPN)
Дальше подгружается JS и начинает работать всякий динамический функционал. То есть, весь фронтенд рендерится на сервере и сохраняется в HTML + JS, а дальше только запросы в API за актуальными данными.
Соответственно, фронтенд можно хоть на Github.io хостить и генерировать при новом PR в Git, а бэкенд на отдельном сервере — и никаких проблем.
Этот бэкенд точно так же, как и PHP, примет запрос, залезет в БД и выдаст JSON ответ.
На фронтенде вообще никто не поймёт, на чём именно бэкенд написан, потому что снаружи будет видно только Nginx, а всё остальное проксируется или в Node, или в php-fpm.
Так в чём разница-то?
Прям надо бросать всё и бежать на Go.
А, так он вот про такой сервер говорил?! Не про бэкенд для веб-сайта?
Так что, по универсальности, это однозначно самый мощный сегодня инструмент.