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

Nhân tiện, một đính chính quan trọng: mặc dù modxSite triển khai API, các yêu cầu không sử dụng dữ liệu json làm đầuเข้า, mà sử dụng multipart/form-data cổ điển

Bây giờ, trong API GraphQL mới của chúng ta, chúng ta cần kiểm tra việc proxy và xử lý yêu cầu.

Tôi đã thêm bản nháp resolver và ngay lúc này tôi có thể kiểm tra xem các yêu cầu có đến trình xử lý MODX hay không và liệu chúng ta có nhận được phản hồi hay không.

Ở đây tôi thấy một phản hồi chính xác ở định dạng JSON cho biết tôi không có quyền truy cập khi cố gắng tạo một yêu cầu.

Nghĩa là bản thân yêu cầu đã được gửi đến trang MODX và được xử lý chính xác. Bây giờ cần phải thêm tính năng ủy quyền người dùng.

Trong tài khoản cá nhân, chúng ta cần tìm cookie phiên hiện tại. Nó có thể được tìm thấy trong phần tiêu đề yêu cầu

hoặc đơn giản hơn là chuyển đến tab Ứng dụng (Application) và xem trong danh sách cookie chung.

Bây giờ cookie này có thể được thêm như một tiêu đề tùy chỉnh trong GraphQL playground của API mới của chúng ta.

Bây giờ, khi gửi yêu cầu kèm theo cookie ủy quyền, chúng ta nhận được phản hồi với danh sách các lỗi trong quá trình xác thực dữ liệu biểu mẫu.

Vậy là xong. Có thể coi như bộ khung của API đã sẵn sàng. Chỉ còn lại việc mô tả các tham số yêu cầu và phản hồi là có thể tích hợp vào frontend.

Dự án này là một cơ hội tuyệt vời để gợi lại những kỹ năng cũ và vui mừng khi thấy một số thứ đã được thiết kế tiện lợi như thế nào từ thời đó :-)

Tôi xin nhắc lại rằng các công cụ hữu ích chính từng được sử dụng trên trang web khi đó và sẽ giúp ích cho chúng ta là console, modxSite và modxSmarty.

Tại sao và bằng cách nào chúng lại giúp ích? Đã được viết tại đây.

Và ngay lúc này, tôi đang kiểm chứng điều đó trong thực tế.

Đầu tiên là việc tạo yêu cầu cấp thẻ ra vào và lấy dữ liệu này. Ở đây, công lớn thuộc về modxSite vì nó cho phép tạo các bộ xử lý (processors) riêng để làm việc với dữ liệu, đi kèm quyền truy cập API có sẵn ngay từ đầu. Thế là trong tài khoản cá nhân ở phía frontend, tôi mở devTools và xem yêu cầu tạo:

Ở đây tôi thấy bộ xử lý nào đang được gọi — passes/visitors/create — và dữ liệu nào đang được truyền đi. Tức là ta đã có thể ném cái này vào Postman hoặc công cụ tương tự để thực hiện các truy vấn.

Nhưng lúc này chúng ta sử dụng thêm một công cụ nữa — console. Và mặc dù tôi đã không viết gì ở đó trong nhiều năm qua, tôi thậm chí còn chẳng phải viết lại gì cả. Nó có tính năng xuất và nhập mã, và ở đây tôi chỉ việc chọn từ danh sách đoạn mã gỡ lỗi đã lưu trước đó. Thế là xong. Có thể chạy trực tiếp ngay trong trang quản trị MODX :-)

Ưu điểm của cách tiếp cận này là logic hoàn toàn tách biệt với giao diện trình bày. Nghĩa là ở đây chúng ta chỉ thao tác với các yêu cầu API, truyền dữ liệu thô và nhận lại dữ liệu thô. Sau đó, chúng ta muốn định dạng phản hồi theo cách nào tùy ý. Trước đây, phản hồi này được xử lý bởi một ứng dụng JavaScript trên trang web MODX, nhưng bây giờ nó sẽ được xử lý trên trang web mới của chúng ta với các công nghệ hoàn toàn mới. Và chúng ta sẽ không cần phải chỉnh sửa bất cứ thứ gì trong MODX cả. Trang web mới chỉ đơn giản là cần biết phải gửi yêu cầu API đi đâu là đủ.

Vì ngay cả trong trung hạn, toàn bộ logic nghiệp vụ vẫn sẽ xoay quanh chính MODX, nhưng phần giao diện (frontend) phải hoạt động hoàn toàn mượt mà trên các công nghệ mới, nên chúng tôi thực hiện đồng bộ dần các tài khoản người dùng vào cơ sở dữ liệu của cỗ máy mới. Cụ thể là khi có yêu cầu từ người dùng hiện tại kèm theo cookie phiên MODX của họ, chúng tôi chỉ cần kiểm tra phiên đó trên backend mới của mình, lấy thông tin người dùng MODX và tạo một người dùng liên kết phía chúng tôi. Đồng thời, chúng tôi thậm chí không cần lưu trữ mật khẩu hay kiểm tra quyền truy cập, vì việc xác thực vẫn diễn ra ở MODX và tất cả các chính sách phân quyền tiếp tục hoạt động ở cấp độ MODX, do mọi thứ ban đầu đều được xây dựng dựa trên API, nên tại đây chúng tôi sẽ chỉ đóng vai trò proxy cho các yêu cầu. Còn ở phía giao diện, chúng tôi chỉ cần biết người dùng đã đăng nhập hay chưa.