Сергей Шлоков

Сергей Шлоков

Был в сети 06 ноября 2025, 19:54
Заказы не принимаю
Вопрос а зачем MODX если делать так:
ПАТАМУШТА. ))

Странно слышать такой вопрос от человека, который не первый год пилит свою систему. Новая админка ничего не ломает и может работать параллельно со старой. А в дальнейшем, если взлетит, то следующий шаг — постепенное отвязывание от старого ядра.

Например, пилотные серии «Игры престолов» провалились.Никто не бросился делать сразу все сезоны. Было принято решение сделать всё заново с другими актерами и сценаристами. И в итоге грандиозный успех.
— RestApi, которое будет работать как бэкенд для любых админок и устанавливаться на любой свежий MODX. Api должно реализовывать текущий функционал админки MODX через её процессоры.
На первом этапе это можно пропустить и задействовать рабочие коннекторы. При работе над админкой картина будущего API станет более ясной. Тут мои знания могу пригодиться.

— VueManager, который будет ставиться и предоставлять альтернативный менеджер, работающий с этим API. Тут только frontend приложение с основным функционалом. Второй этап — продумать его расширение дополнениями. У Vue.js есть, например, система событий на которую можно подписываться и что-то делать.
А вот тут я мимо. Знания самые базовые.

И тогда мы получим свою MODX-Like CMS, которая будет работать на тех же идеях, но написанную с нуля и без тяжелого наследия времён Etomite CMS.
Абсолютли )
Ну или возьмем пример из топика. Что сделал ТС? Он подцепился к API modx.pro который разработал Василий и завернул ответ в GraphQL. И тут напрашивается резонный вопрос, а зачем нам этот промежуточный слой в виде уже существующего /assets/components/extras/action.php, если у нас есть доступ к коду и можно сразу сформировать GraphQL
Насколько я понимаю, доступа к коду как раз и нет. У него же нет другой точки входа с описанными схемами или доступа к БД напрямую. Поэтому и пришлось юзать что дали. Или есть? )

И одна из них webonyx/graphql-php взята за основу для Railt
Хотя сам Кирилл её не хвалит )
Зацепил меня данный комментарий. Думал после видео что-нибудь кто-нибудь ответит, но нет)
Я ещё первое до конца не досмотрел. А второе вообще 3 часа. ))

Если мы берем за аксионму тот факт, что GraphQL это чисто JS, а проект на PHP, то реализация API потребует абсолютно другого технологического стека.
Я имел ввиду немного другое. Конечно не надо менять стеки. Я хотел сказать, что нет особой необходимости использовать GraphQL для PHP разработчиков. Если только у тебя не мега сервис с могущим API, как говорит Кирилл Несмеянов.Т.е.PHP разработчику вполне хватит REST-а.

А вот если посмотреть со стороны фронт разработчика, то ему GraphQL даёт больше плюшек. Он не знает ни схем, ни связей объектов в отличие от PHP разработчика (и любого другого бекэндера). И GraphQL даёт ему возможность самому строить запросы не зная этого.

Попробую пояснить мысль. Представим, что MODX — это сервис с API, как это изначально планировалось сделать в MODX3 — использовать Slim в качестве ядра и работать через API. Тогда можно подключать любую админку. Как мне кажется (!), тут GraphQL в качестве обёртки не нужен. Вполне хватит обычного REST-а.

П.С. Возможно, я говорю глупости. Просто ещё не до конца вкурил эту тему. :)
Посмотрел. Заинтересовало. Но… GraphQL — это как бы альтернатива REST-у. Придумана фронтэндерами. Удобно. Но в экосистеме MODX я не встречал даже какой-то толковой наработки по RESTful. Поэтому GraphQL вряд ли будет востребован разработчиками, использующими MODX. И это не удивительно. Могу ошибаться, но скорее всего и в WP, Joomla и т.п. CMS такого тоже не увидишь. Это другой уровень.
В свете сказанного, GraphQL выглядит немного неуместно для PHP. Как и для любого другого серверного языка. А вот для JS самое оно. Фронтэндеру не нужно разбираться в связях и типах. Всё прописано в схемах.
Но это, как требует говорить Николай, чисто моё мнение.