Nhiệm vụ: Tổ chức tích hợp frontend mới với backend MODX hiện có

Теперь уже в нашем новом GraphQL-апи надо протестировать проксирование и обработку запросов.

Я добавил черновик резолвера и уже сейчас могу проверить идут попадают ли запросы в обработчик MODX и прилетает ли нам ответ.

Вот я вижу корректный ответ в формате JSON о том, что у меня нет доступа при попытке создать заявку.

То есть сам запрос на MODX-сайт улетает и корректно отрабатывается. Сейчас необходимо добавить выторизацию пользователя.

В личном кабинете нам надо найти текущую куку сессии. Ее можно найти или в заголовках запросов

или еще проще - перейти во вкладку Приложение и посмотреть в общем списке кукисов.

Теперь эту куку можно добавить как кастомный заголовок в GraphQL playground нашего нового апи.

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

Все. Можно считать, что сам каркас АПИ готов. Остается только параметры запросов и ответов описать и можно прикручивать на фронт.

Кстати, важное уточнение: несмотря на то, что modxSite реализует АПИ, запросы используют не json данные на вход, а классический multipart/form-data

Так как даже в среднесрочной перспективе вся бизнес-логика будет все еще крутиться в самом MODX, но фронтовая часть вся должна работать бесшовно на новых технологиях, то делаем постепенную синхронизацию пользовательских учеток в базу данных нового движка. То есть когда прилетает запрос текущего пользователя с его кукой MODX-сессии, то мы на своем новом бэкэнде просто проверяем его сессию и получаем MODX-пользователя, и заводим связанного пользователя у нас. При этом нам не надо даже сохранять у себя пароль и проверять доступы, так как проверяка все равно идет потом в MODX и все политики доступов продолжают работать на уровне MODX, так как у нас изначально все делалось на API, так что тут мы запросы будем просто проксировать. А на фронте нам только надо знать авторизован пользователь или нет.

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

Напомню, что основные полезный инструменты, которые тогда использовались на сайте и должны нам помочь - это console, modxSite и modxSmarty.

Почему и как должны помочь? Написано тут.

И вот сейчас я на практике в этом убеждаюсь.

Для начала создание заявок на пропуска и получение этих данных. Здесь заслуга modxSite в том, что она позволяет делать свои процессоры для работы с данными. При этом из коробки API доступ. И вот я в личном кабинете на фронте открываю devTools и смотрю запрос на создание:

Здесь я вижу какой процессор вызывается - passes/visitors/create и какие данные передаются. То есть это уже можно засунуть в какой-нить postman или типа того и выполнять запросы.

Но тут мы берем еще один инструмент - консоль. И хотя я уже много лет ничего не писал там, мне даже не пришлось ничего писать. В ней есть функционал экспорта и импорта кода, и тут я просто выбрал из списка ранее сохраненный отладочный код. И все. Можно выполнять прям в MODX-админке :-)

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