Vì sao tôi từ bỏ GraphQL sau 6 năm

• Sau 6 năm sử dụng từ 2018, tôi từng là một fan cuồng GraphQL thực thụ, nhưng giờ đã bắt đầu hoài nghi
• Tôi muốn giải thích vì sao giờ đây mình không còn khuyến nghị GraphQL nữa và đâu là giải pháp thay thế tốt hơn theo quan điểm của tôi

Bề mặt tấn công

• GraphQL làm tăng rủi ro mở rộng bề mặt tấn công khi phơi bày một ngôn ngữ truy vấn.
• Các vấn đề liên quan đến phân quyền đặc biệt quan trọng.
  • Cần kiểm tra phân quyền phù hợp cho mọi trường.
  • Với REST API, việc kiểm tra quyền theo từng endpoint đơn giản hơn.

Phân quyền

• Cần xác minh quyền người dùng cho mọi trường.
• Với REST API, việc kiểm tra quyền theo từng endpoint đơn giản hơn.

Giới hạn tốc độ

• Truy vấn GraphQL không có giới hạn kích thước nên có thể gây tải lớn cho máy chủ.
• Có thể ước tính độ phức tạp của truy vấn và giới hạn những truy vấn vượt quá một mức độ phức tạp nhất định.
• Với REST API, việc giới hạn số lượng request đơn giản hơn.

Phân tích truy vấn

• Chuỗi truy vấn sai có thể khiến máy chủ sử dụng bộ nhớ quá mức.
• Có thể đặt số lượng lỗi tối đa để dừng quá trình phân tích.

Hiệu năng

Lấy dữ liệu và vấn đề N+1

• Field resolver có thể gọi nguồn dữ liệu bên ngoài nhiều lần.
• Có thể dùng mẫu Dataloader để giải quyết vấn đề này.
• Với REST, việc xử lý vấn đề N+1 trong controller đơn giản hơn.

Phân quyền và vấn đề N+1

• Mã phân quyền có thể gây ra vấn đề N+1.
• Với REST, vấn đề này không xảy ra.

Sự gắn kết

• Codebase GraphQL có business logic gắn chặt với tầng truyền tải.
• Cần kiểm thử tích hợp và việc debug cũng khó khăn hơn.

Độ phức tạp

• Nhiều phương pháp khác nhau để xử lý các vấn đề bảo mật và hiệu năng của GraphQL làm tăng độ phức tạp của codebase.
• Các giải pháp REST nhìn chung đơn giản hơn.

Giải pháp thay thế

• Tác giả khuyến nghị JSON REST API sử dụng OpenAPI 3.0+.
• Nếu có client được viết bằng ngôn ngữ kiểu tĩnh, OpenAPI có thể là lựa chọn tốt hơn.
• OpenAPI có thể tự động sinh mã client an toàn kiểu dữ liệu.

Ý kiến của GN⁺

• GraphQL rất mạnh, nhưng cần nhiều nỗ lực để giải quyết các vấn đề về bảo mật và hiệu năng.
• REST API tương đối đơn giản và trong nhiều trường hợp có thể phù hợp hơn.
• OpenAPI cung cấp type safety và các công cụ tự động hóa, giúp nâng cao năng suất phát triển.
• Khi áp dụng GraphQL, cần cân nhắc đầy đủ các vấn đề về bảo mật và hiệu năng.
• Điều quan trọng là phải so sánh ưu và nhược điểm của REST và GraphQL để chọn công nghệ phù hợp với dự án.

[savvykang]

Lý do tôi từ bỏ GraphQL sau 6 năm

[yangeok]

Thời đại bùng nổ của RPC đang đến

[ahwjdekf]

Đúng là vậy mà... Không thể cứ thấy thứ gì đó hào nhoáng xuất hiện là vồ lấy rồi tung hô được.. Giờ đến lượt ORM rồi. Ngày của mày cũng không còn xa đâu...

[rockmkd]

ORM đã xuất hiện hơn 20 năm rồi mà...

[cometkim]

Đến năm 2018 thì PQ cũng không còn quá mới nữa (thực ra đã được khuyến nghị ngay từ khi GraphQL lần đầu được công bố), nên khá ngạc nhiên là họ đã không thử trong suốt 6 năm...

[surfindia]

Do tất cả những lý do đã nêu ở trên, việc tự tay triển khai toàn bộ GraphQL là khó khăn về cả độ phức tạp lẫn tính ổn định. Có lẽ sẽ tốt hơn nếu đặt một layer như hasura hoặc postgraphile lên trên DB, rồi tùy nhu cầu mà phát triển theo cách bổ sung graphql hay rest vào layer này.

[GN⁺]

Ý kiến Hacker News

• Sau khi áp dụng GraphQL đã gặp rất nhiều vấn đề. Không còn muốn dùng nữa vì các vấn đề về quản lý quyền hạn và hiệu năng. Có thể phù hợp nếu chỉ dùng ở frontend, nhưng tích hợp với backend thì phức tạp.
• Sau khi học REST trước rồi dùng thử gRPC, API an toàn kiểu dữ liệu rất hấp dẫn. GraphQL không có nhiều lợi ích, chỉ thực sự hữu ích khi hoạt động giống như một cơ sở dữ liệu.
• Đã làm việc ở hai dự án GraphQL; ban đầu khởi đầu nhỏ nhưng theo thời gian trở nên phức tạp. Khó debug và phát sinh vấn đề hiệu năng. REST và RPC đơn giản hơn, dễ quản lý hơn.
• Với tư cách là người sáng lập Hasura, đã chứng kiến sự tiến hóa của việc sử dụng GraphQL. GraphQL rất khó xây dựng nếu không có data layer. Dùng GraphQL trên REST thì kém hiệu quả. Trường hợp sử dụng chính của GraphQL là khi có nhiều bên tiêu thụ dữ liệu.
• Các kỹ sư frontend lưu truy vấn vào thư viện trung tâm và tái sử dụng, điều này chẳng khác nào dùng GraphQL như REST.
• Từ kinh nghiệm dùng OpenAPI, GraphQL, JSON/HTTP và gRPC, việc giới hạn truy vấn GraphQL có thể giảm bớt các vấn đề về hiệu năng và bảo mật. Buf Connect là điểm thỏa hiệp phù hợp nhất cho đa số dự án.
• Từ kinh nghiệm dùng GraphQL tại Facebook, nhiều người thực ra không có những vấn đề mà GraphQL cố giải quyết. Facebook dùng GraphQL để xử lý versioning và mô hình đối tượng phức tạp.
• Lý do GraphQL hoạt động tốt ở Facebook là vì mọi người dùng đều đăng nhập, và bảo mật đã được tích hợp vào từng field. Nếu có SPA và yêu cầu đăng nhập, GraphQL có thể hữu ích.
• Khi dùng GraphQL, lúc đầu thấy tốt nhưng cuối cùng lại cần rất nhiều công việc bổ sung và trùng lặp. Sẽ tốt hơn nếu bắt đầu với endpoint kiểu JSON-RPC rồi thêm những tính năng cần thiết.
• Khi dùng GraphQL trong một dự án nhỏ, gần như mọi thứ đều tốt. Đã dùng Apollo Client và graphql-codegen để tạo type và hàm cho Vue 3. Có một số vấn đề, nhưng nó bắt được rất nhiều lỗi ở cấp độ kiểu dữ liệu.