Task: Organize integration of the new frontend with the existing MODX backend

By the way, an important clarification: despite the fact that modxSite implements an API, the requests use classical multipart/form-data instead of JSON data as input

Now, in our new GraphQL API, we need to test proxying and request processing.

I've added a resolver draft and right now I can check whether requests are reaching the MODX handler and whether we are getting a response back.

Here I see a correct response in JSON format stating that I don't have access when trying to create a request.

This means the request itself is sent to the MODX site and processed correctly. Now we need to add user authorization.

In the personal account, we need to find the current session cookie. It can be found either in the request headers

or even simpler - go to the Application tab and look in the general list of cookies.

Now this cookie can be added as a custom header in the GraphQL playground of our new API.

Now, by sending a request with the authorization cookie, we get a response with a list of errors during form data validation.

That's it. We can consider the API framework itself ready. All that remains is to describe the request and response parameters, and we can hook it up to the frontend.

This project is a great opportunity to blow the dust off some old skills and be glad at how conveniently certain things were already designed back then :-)

Let me remind you that the main useful tools used on the site back then and which should help us now are console, modxSite, and modxSmarty.

Why and how should they help? It's written here.

And right now, I am seeing this for myself in practice.

First, creating pass requests and retrieving this data. Here, the credit goes to modxSite because it allows you to create your own processors for working with data, with API access available out of the box. So, in the personal account on the frontend, I open devTools and look at the create request:

Here I can see which processor is being called — passes/visitors/create — and what data is being transmitted. That means this can already be plugged into Postman or something similar to execute requests.

But then we take another tool — the console. And even though I haven't written anything there for many years, I didn't even have to write anything this time. It has a code export and import functionality, and here I just selected previously saved debugging code from the list. And that's it. You can run it right in the MODX admin panel :-)

The advantage of this approach is that the logic is completely separated from the presentation. That is, here we simply operate with API requests, transmit pure data, and receive pure data in response. And we can then style the response however we want. Previously, this response was processed by a JavaScript application on the MODX site, but now it will be handled by our new site using completely new technologies. And we won't have to change anything at all in MODX. The new site simply needs to know where to send API requests, and that's it.

Since even in the medium term all the business logic will still revolve around MODX itself, but the entire frontend must work seamlessly on new technologies, we are implementing a gradual synchronization of user accounts into the database of the new engine. That is, when a request from the current user arrives with their MODX session cookie, we simply check their session on our new backend, retrieve the MODX user, and create a linked user on our side. At the same time, we don't even need to store the password or check access rights, since verification still goes through MODX anyway, and all access policies continue to work at the MODX level, as everything was originally built on the API here, so we will simply proxy the requests. And on the frontend, we only need to know whether the user is authorized or not.