🙅♀️ Tại sao GraphQL không nên có trong WordPress core
Cập nhật 01/05/2024: Xem thêm bài so sánh Gato GraphQL vs WP REST API.
Vâng, bạn đọc tiêu đề đó đúng rồi. Mặc dù chính tôi là người tạo ra một máy chủ GraphQL cho WordPress, tôi đã thay đổi quan điểm về việc liệu WordPress có nên đi kèm với GraphQL hay không.
Cho đến không lâu trước đây, tôi tin rằng GraphQL nên có trong WordPress core. Logic là các cộng tác viên đang dành thời gian và công sức để triển khai các tính năng cho WP REST API (các thao tác hàng loạt) vốn là tính năng bản địa của GraphQL.
Tuy nhiên, gần đây tôi đã tìm hiểu được một số thông tin mới khiến tôi phải suy nghĩ lại, và bây giờ tôi cho rằng WordPress không nên đi kèm với GraphQL, vì những rủi ro bổ sung mà nó mang lại.
Đây là những lý do của tôi.
1. Nó không đáp ứng quy tắc 80/20
Theo lịch sử, một tính năng nhất định chỉ được thêm vào WordPress core nếu nó đáp ứng quy tắc 80/20, có nghĩa là 80% hoặc nhiều hơn người dùng sẽ sử dụng nó.
Liệu điều đó có xảy ra với GraphQL không? Tôi nghĩ câu trả lời là "không", dựa trên tiền lệ từ việc giới thiệu WP REST API vào WordPress 4.7.
Trong bài nói chuyện WordPress as Data, 5 Years In, K. Adam White (người dẫn đầu chính của quá trình phát triển và phát hành ban đầu của WP REST API) đã mô tả rằng các cộng tác viên kỳ vọng REST API sẽ được sử dụng rộng rãi sau khi được phát hành cùng core. Nhưng điều đó đã không xảy ra: các nhà phát triển vẫn tiếp tục xây dựng các trang WordPress theo cách như trước, ít chú ý đến "headless" hay REST API.
Mọi thứ chỉ thay đổi sau đó, với việc giới thiệu trình soạn thảo Gutenberg trong WordPress 5.0, vốn được xây dựng dựa trên REST API. Liệu Gutenberg có thể biện minh cho việc thêm GraphQL vào WordPress core không?
2. Headless đã được đáp ứng qua REST API
Trình soạn thảo WordPress có thể được nâng cao với một máy chủ GraphQL bản địa, cho phép các nhà phát triển block sử dụng GraphQL (ngoài REST API hiện có) để lấy dữ liệu cho các block của họ. Ngoài ra, các theme và plugin có thể sử dụng GraphQL để hỗ trợ các chức năng nội bộ của mình. Đây là những lý do thuyết phục để thêm GraphQL vào WordPress core.
Tuy nhiên, WordPress đã có REST API rồi, và bất cứ điều gì bạn có thể làm với GraphQL cũng có thể làm với REST. Giới thiệu GraphQL bên cạnh REST giống như mua một chiếc BMW khi bạn đang lái một chiếc Toyota. Bạn sẽ đến đích nhanh hơn, và trải nghiệm lái xe sẽ hấp dẫn hơn. Nhưng cả hai xe đều sẽ đưa bạn đến nơi bạn muốn đi.
Vì GraphQL sẽ không cung cấp một tính năng chưa từng có trước đây, nên việc đưa nó vào core không hoàn toàn có cơ sở. GraphQL chắc chắn sẽ nâng cao trải nghiệm tương tác với API, nhưng điều này hoàn toàn có thể được coi là thuộc phạm vi plugin.
3. Các theme và plugin WordPress có thể sử dụng webonyx/graphql-php
Các plugin công khai không thể yêu cầu một trang web phải cài đặt WPGraphQL hoặc Gato GraphQL để sử dụng plugin, vì điều đó sẽ thu hẹp phạm vi tiếp cận tiềm năng của chúng. Vì vậy, các plugin công khai không thể dựa vào GraphQL, và đó là điều thực sự đáng tiếc.
Tôi đã suy nghĩ nhiều về vấn đề này, và đã nghĩ ra một giải pháp tiềm năng: GraphQL API Private, một engine GraphQL độc lập mà các plugin có thể nhúng vào để sử dụng riêng, được phân phối như một gói Composer. (Tôi chưa bắt đầu làm việc trên dự án này.)
Nhưng sau đó, vài tuần trước, một plugin WordPress được hỗ trợ bởi GraphQL đã được phát hành. Tôi tự hỏi tác giả đã làm điều đó như thế nào: liệu nó có sử dụng WPGraphQL hay Gato GraphQL bên dưới không? Vì vậy tôi đã kiểm tra mã nguồn của nó và, hóa ra, nó đang trực tiếp sử dụng webonyx/graphql-php!
Đây là một giải pháp thú vị, chứng minh rằng, với một chút nỗ lực, các nhà phát triển hiện tại đã có quyền truy cập GraphQL cho các theme và plugin của họ.
Plugin này sử dụng GraphQL để lấy các thực thể dữ liệu của chính nó, chứ không phải dữ liệu của WordPress (bài viết, người dùng, bình luận, v.v.). Vì vậy, nó không cần phải tái tạo schema GraphQL chứa mô hình dữ liệu WordPress, như WPGraphQL và Gato GraphQL đã làm (và cuối cùng là GraphQL API Private). Do đó, việc dựa vào webonyx/graphql-php là hợp lý.
4. GraphQL đặt ra những rủi ro bổ sung
Ba vấn đề trên cho thấy GraphQL sẽ nâng cao WordPress, dù không đặc biệt thuyết phục. Trong bối cảnh đó, chúng ta vẫn có thể thêm GraphQL vào WordPress core, và hoặc là hưởng lợi từ nó hoặc không có gì thay đổi.
Nhưng vấn đề thứ 4 này cho thấy rằng, nếu GraphQL không mang lại nhiều giá trị cho WordPress, thì nó không nên được thêm vào, vì những rủi ro bổ sung mà nó mang lại.
GraphQL dễ bị tổn thương bởi các vector tấn công sau (trong số những cái khác):
- Endpoint duy nhất cung cấp quyền truy cập vào tất cả thông tin từ trang web, vì vậy chúng ta có thể có dữ liệu riêng tư bị lộ ngoài ý muốn.
- Các queries có thể rất phức tạp và có thể làm quá tải máy chủ web và cơ sở dữ liệu.
- Cùng một mutation có thể được thực thi nhiều lần trong một query duy nhất, và nhiều queries có thể được thực thi cùng nhau trong một yêu cầu duy nhất, cho phép kẻ tấn công cố gắng truy cập vào back-end bằng cách cung cấp nhiều tổ hợp tên người dùng/mật khẩu.
Những cuộc tấn công này có thể thực sự gây hại. Trong bài thuyết trình Damn GraphQL - Defending and Attacking APIs, nhà nghiên cứu an ninh mạng Dolev Farhi đã xoay sở để hạ gục một trang WordPress trong vòng chưa đầy 30 giây, bằng cách tấn công endpoint WPGraphQL với một loạt các queries phức tạp.
Nhóm WPGraphQL đã vá lỗi ngay lập tức. Nhưng làm sao chúng ta có thể chắc chắn rằng không có khai thác nào khác có thể xảy ra? (Ý tôi không chỉ là WPGraphQL, mà còn cả Gato GraphQL.)
Những cuộc tấn công này có thể xảy ra với GraphQL, mà không phải với REST, vì GraphQL mạnh hơn REST. Trong khi với REST, query được định nghĩa trước và lưu trữ trên máy chủ, thì trong GraphQL, nó được cung cấp tại thời điểm chạy bởi client (trừ khi sử dụng persisted queries).
Nếu các quản trị viên trang web lơ là trong việc cấu hình ai có thể truy cập endpoint, hay dữ liệu nào bị lộ, thì những điều tệ hại có thể xảy ra. Và do sự phổ biến của WordPress, được sử dụng bởi hàng triệu người không am hiểu về công nghệ, thì những điều tệ hại sẽ rất có thể xảy ra.
Tổng kết
Chỉ để chắc chắn: Tôi không đề xuất không sử dụng GraphQL trong WordPress (tất nhiên là không!), mà là sử dụng GraphQL một cách có trách nhiệm. GraphQL rất mạnh, điều đó có nghĩa là nó nguy hiểm. Khi sử dụng GraphQL, chúng ta cần chắc chắn rằng mình biết mình đang làm gì.
Đưa GraphQL vào WordPress core sẽ đặt nó vào tay rất nhiều người, nhiều người trong số đó sẽ không nhận thức được các rủi ro của nó, và không thực hiện các biện pháp thích hợp. Đó là một công thức dẫn đến thảm họa tiềm tàng. Và vì vậy, đó bây giờ là quan điểm của tôi, nó nên được tránh.