Có bất kỳ nhược điểm nào đối với GraphQL không? [đóng cửa]

Tất cả các bài viết về GraphQL sẽ cho bạn biết nó tuyệt vời như thế nào, nhưng nó có bất kỳ nhược điểm hoặc thiếu sót nào không? Cảm ơn bạn.

Nhược điểm:

• Bạn cần học cách thiết lập GraphQL. Hệ sinh thái vẫn đang phát triển nhanh chóng nên bạn phải theo kịp.
• Bạn cần gửi các truy vấn từ máy khách, bạn chỉ có thể gửi chuỗi nhưng nếu bạn muốn thoải mái hơn và lưu vào bộ nhớ đệm, bạn sẽ sử dụng thư viện máy khách -> mã bổ sung trong máy khách của bạn
• Bạn cần xác định lược đồ trước => làm thêm trước khi có kết quả
• Bạn cần có một điểm cuối graphql trên máy chủ của mình => các thư viện mới mà bạn chưa biết
• Các truy vấn Graphql có nhiều byte hơn là chỉ đơn giản là đi đến một điểm cuối REST
• Máy chủ cần xử lý nhiều hơn để phân tích cú pháp truy vấn và xác minh các tham số

Nhưng, những điều đó còn nhiều hơn những điều sau:

• GraphQL không khó để học
• Mã bổ sung chỉ có vài KB
• Bằng cách xác định một lược đồ, bạn sẽ ngăn chặn được nhiều công việc hơn sau khi sửa lỗi và bền bỉ nâng cấp
• Có rất nhiều người chuyển sang GraphQL nên có một hệ sinh thái phong phú đang phát triển, với công cụ tuyệt vời
• Khi sử dụng các truy vấn liên tục trong sản xuất (thay thế các truy vấn GraphQL chỉ bằng một ID và các tham số), bạn thực sự gửi ít byte hơn so với REST
• Xử lý thêm cho các truy vấn đến là không đáng kể
• Cung cấp một sự tách biệt rõ ràng của API và phụ trợ cho phép lặp lại nhanh hơn nhiều trên các ứng biến phụ trợ

Tôi đã tìm thấy một số mối quan tâm quan trọng đối với bất kỳ ai đang cân nhắc sử dụng GraphQL và cho đến nay các điểm chính là:

Truy vấn độ sâu không xác định : GraphQL không thể truy vấn độ sâu không xác định, vì vậy nếu bạn có một cây và muốn trả về một nhánh mà không biết độ sâu, bạn sẽ phải thực hiện một số phân trang.

Cấu trúc phản hồi cụ thể : Trong GraphQL, phản hồi phù hợp với hình dạng của truy vấn, vì vậy nếu bạn cần phản hồi trong một cấu trúc rất cụ thể, bạn sẽ phải thêm một lớp chuyển đổi để định hình lại phản hồi.

Bộ nhớ cache ở cấp độ mạng : Do cách GraphQL được sử dụng phổ biến qua HTTP (A POST trong một điểm cuối duy nhất), bộ nhớ cache ở cấp độ mạng trở nên khó khăn. Một cách để giải quyết nó là sử dụng Truy vấn liên tục.

Xử lý tải lên tệp : Không có gì về tải lên tệp trong đặc tả GraphQL và các đột biến không chấp nhận tệp trong đối số. Để giải quyết vấn đề này, bạn có thể tải lên tệp bằng cách sử dụng các loại API khác (như REST) ​​và chuyển URL của tệp đã tải lên đến đột biến GraphQL hoặc đưa tệp vào ngữ cảnh thực thi, vì vậy bạn sẽ có tệp bên trong các hàm của trình phân giải.

Thực thi không thể đoán trước : Bản chất của GraphQL là bạn có thể truy vấn kết hợp bất kỳ trường nào bạn muốn nhưng tính linh hoạt này không miễn phí. Có một số mối quan tâm cần biết như Hiệu suất và Truy vấn N + 1.

Các API siêu đơn giản : Trong trường hợp bạn có một dịch vụ hiển thị một API thực sự đơn giản, GraphQL sẽ chỉ tăng thêm độ phức tạp, vì vậy một API REST đơn giản có thể tốt hơn.

Vấn đề lớn nhất mà tôi thấy với graphQL, tức là nếu bạn đang sử dụng với cơ sở dữ liệu quan hệ là với các phép nối .

1. Thực tế là bạn có thể cho phép / không cho phép một số trường làm cho các phép nối trở nên không tầm thường (không đơn giản). Dẫn đến các truy vấn bổ sung.

2. Ngoài ra, các truy vấn lồng nhau trong graphql dẫn đến các truy vấn vòng tròn và có thể làm hỏng máy chủ . Cần phải cẩn thận hơn.

3. Việc giới hạn tốc độ cuộc gọi trở nên khó khăn vì giờ đây người dùng có thể kích hoạt nhiều truy vấn trong một cuộc gọi.

MẸO : Sử dụng dataloader của facebook để giảm số lượng truy vấn trong trường hợp javascript / node

Nó ngày càng tốt hơn mỗi năm, và hiện tại, cộng đồng GraphQL đang phát triển và kết quả là có nhiều giải pháp hơn cho rất nhiều vấn đề đã được nêu trong các câu trả lời khác trước đây. Nhưng để thừa nhận điều gì vẫn đang ngăn cản các công ty ném mọi nguồn lực vào GraphQL, tôi muốn liệt kê một số vấn đề và giải pháp tiếp theo là những vấn đề chưa được giải quyết.

• Bộ nhớ cache ở cấp độ mạng - như Bruno đã nói đó là Truy vấn liên tục và tất nhiên bạn có thể lưu vào bộ nhớ cache trên máy khách và không ai ngăn bạn sử dụng bộ nhớ đệm ở cấp cơ sở dữ liệu hoặc thậm chí là Redis. Nhưng tất nhiên vì GraphQL chỉ có một điểm cuối và mỗi truy vấn khác nhau - việc thực hiện loại bộ nhớ đệm này phức tạp hơn nhiều so với REST.
• Các truy vấn lồng nhau trong GraphQL dẫn đến các truy vấn vòng tròn và có thể làm sập máy chủ - không còn là vấn đề nữa với rất nhiều giải pháp. Một số trong số họ được liệt kê ở đây
• Xử lý File Upload - chúng tôi đã rất nhiều các giải pháp cho nó

Nhưng có một vài trường hợp khác có thể được coi là bất lợi:

• boilerplate quá mức (ý tôi là đối với việc tạo truy vấn mới, ví dụ, bạn cần xác định lược đồ, trình giải quyết và bên trong trình giải quyết để nói rõ ràng GraphQL cách giải quyết dữ liệu và trường của bạn bên trong, về phía máy khách, hãy tạo truy vấn với chính xác các trường liên quan đến dữ liệu này)
• xử lý lỗi - Tôi cần phải nói rằng nó liên quan nhiều hơn đến việc so sánh với REST. Có thể ở đây với apollo nhưng đồng thời phức tạp hơn nhiều so với REST
• xác thực và ủy quyền - nhưng như tôi đã nói cộng đồng đang gia tăng với tốc độ vượt trội và có đã vài các giải pháp cho mục tiêu này.

Tóm lại, GraphQL chỉ là một công cụ cho các mục tiêu cụ thể và chắc chắn nó không phải là viên đạn bạc cho mọi vấn đề và tất nhiên không phải là sự thay thế cho REST.

Thực sự tuyệt vời khi có một điểm cuối duy nhất và hiển thị tất cả dữ liệu. Tôi thấy những điểm dưới đây cần được xem xét cho GraphQL:

1. Việc triển khai Tải xuống / Tải lên Tệp khá phức tạp (chuyển đổi thành chuỗi có thể không phải là lựa chọn tốt nhất cho các tệp lớn)
2. Rất nhiều mã soạn sẵn và mã lược đồ ở cả giao diện người dùng và phụ trợ.
3. Theo dõi và hỗ trợ phân trang được cung cấp trong đặc tả GraphQL.
4. Cho phép thứ tự tùy chỉnh và logic ưu tiên sắp xếp các trường. Ví dụ nếu chúng tôi tìm nạp dữ liệu người dùng và các nhóm và vai trò được liên kết. Người dùng có thể sắp xếp nhiều dữ liệu dựa trên tên người dùng, tên nhóm hoặc tên vai trò.
5. Xác thực và Ủy quyền sẽ phụ thuộc vào khung phụ trợ.
6. Đảm bảo tối ưu hóa phần phụ trợ và hỗ trợ Cơ sở dữ liệu để kích hoạt một truy vấn cho mỗi lệnh graphql có thể gặp khó khăn.

Ngoài ra, người ta nên xem xét các Ưu điểm sau khi thực hiện:

1. Rất linh hoạt để hỗ trợ các mặt hàng mới và cập nhật hành vi hiện có.

2. Dễ dàng thêm điều kiện bằng cách sử dụng các đối số và thứ tự tùy chỉnh sau khi được triển khai

3. Sử dụng nhiều bộ lọc tùy chỉnh và loại bỏ tất cả các hành động cần được tạo, ví dụ người dùng có thể có id, tên, v.v. làm đối số và thực hiện lọc. Ngoài ra, các bộ lọc cũng có thể được áp dụng trên các nhóm trong người dùng.

4. API dễ kiểm tra bằng cách tạo tệp chứa tất cả các truy vấn và đột biến GraphQL.
5. Các đột biến rất đơn giản và dễ thực hiện khi đã hiểu khái niệm.
6. Cách mạnh mẽ để tìm nạp nhiều độ sâu của dữ liệu.
7. Hỗ trợ Voyager và GraphiQL UI hoặc Playground giúp bạn dễ dàng xem và sử dụng.
8. Dễ dàng cung cấp tài liệu trong khi xác định lược đồ với các phương pháp mô tả hợp lệ.

Tôi nghĩ rằng graphql vào lúc này phải là một phần của kiến ​​trúc phụ trợ, để tải tệp lên, bạn vẫn gặp phải một api bình thường