GraphQL là gì?

Trình duyệt Scrapeless Agent có thể chạy một trang trình duyệt tải dữ liệu thông qua các yêu cầu GraphQL như một phần của quy trình làm việc trên web được ủy quyền.

GraphQL là một ngôn ngữ truy vấn và mô hình thực thi cho các API được xây dựng xung quanh một sơ đồ kiểu. Một khách hàng yêu cầu các trường được đặt tên, và một máy chủ giải quyết các trường đó thành một kết quả được định hình giống như sự lựa chọn. Điều này khác với một giao diện, nơi mà mỗi URL trả về một đại diện cố định. Sự phân biệt này rất hữu ích khi một ứng dụng cần dữ liệu liên quan ở các mức độ chi tiết khác nhau trên các màn hình.

GraphQL không xác định nơi dữ liệu nền tảng cư trú hoặc làm cho một yêu cầu an toàn chỉ vì nó có một sơ đồ. Dịch vụ vẫn cần các bộ giải quyết, xác thực, ủy quyền, giới hạn hoạt động và thỏa thuận vận chuyển. Hướng dẫn này đi qua một yêu cầu từ sơ đồ đến kết quả và sau đó xem xét nơi mà GraphQL giúp đỡ hoặc làm phức tạp một sự tích hợp.

Sơ đồ là hợp đồng API

Một lược đồ GraphQL đặt tên cho các kiểu, trường, tham số và điểm vào hoạt động. Một trường có thể trả về một giá trị nguyên thuần, một đối tượng, một danh sách, hoặc một giá trị có thể là null tùy theo hệ thống kiểu. hướng dẫn sơ đồ chính thức giải thích cách các khai báo này xác định những gì mà khách hàng có thể yêu cầu. Một khách hàng không thể đơn giản yêu cầu các cột cơ sở dữ liệu tùy ý vì họ có thể viết tên trường trong một truy vấn.

Một sơ đồ làm cho các mối quan hệ trở nên rõ ràng. Một loại mặt hàng có thể tiết lộ một tiêu đề và một trường người bán, trong khi loại người bán tiết lộ một tên hiển thị. Một khách hàng có thể chọn tiêu đề và tên người bán được lồng ghép trong một thao tác nếu sơ đồ cho phép điều đó. Máy chủ quyết định cách lấy những giá trị đó. Quyết định đó có thể liên quan đến một cơ sở dữ liệu, một dịch vụ khác, hoặc một kết quả đã được lưu vào bộ nhớ đệm.

Tính khả null là một phần của hợp đồng. Nó mô tả liệu một trường có thể vắng mặt trong phản hồi hợp lệ hay không, chứ không phải lý do tại sao nguồn gốc cơ sở lại thất bại. Các khách hàng nên tạo ra và kiểm tra theo sơ đồ, nhưng họ vẫn phải xử lý lỗi ứng dụng và chất lượng dữ liệu. Một khai báo không-null không thể làm cho một nguồn phía trên không đáng tin cậy trở nên hoàn chỉnh một cách thần kỳ.

Cách một truy vấn GraphQL có hình dáng của nó

Một hoạt động truy vấn bắt đầu từ gốc truy vấn và chọn các trường xuống các lá vô hướng. The hướng dẫn truy vấn chính thức cho thấy một khách hàng xác định chính xác các trường mà họ muốn từ một sơ đồ cụ thể. Các đối số có thể lọc hoặc xác định dữ liệu, và các biến cho phép khách hàng cung cấp các giá trị riêng biệt với văn bản truy vấn. Dữ liệu phản hồi phản ánh cấu trúc trường đã chọn.

Lựa chọn này có thể giảm bớt các trường không cần thiết cho một màn hình chỉ cần một tóm tắt. Nó cũng có thể kết hợp các trường liên quan mà nếu không sẽ yêu cầu vài yêu cầu tài nguyên. Không một kết quả nào là tự động. Máy chủ có thể vẫn thực hiện công việc tốn kém cho một trường lồng ghép, và khách hàng có thể yêu cầu nhiều hơn nhiều so với những gì màn hình cần. Lựa chọn trường cung cấp sự linh hoạt mà cần kiểm soát chi phí.

Một mô hình tư duy hữu ích là thực đơn nhà hàng với những lựa chọn rõ ràng, nhưng kết quả thì nghiêm ngặt hơn một phép ẩn dụ: các tên và loại được xác thực theo sơ đồ trước khi thực hiện. Một trường bị viết sai tạo ra một lỗi xác thực thay vì một thuộc tính trống. Kiểm tra sớm đó giúp các nhà phát triển phát hiện sự không khớp hợp đồng trước khi giải thích một kết quả phần mờ nhạt.

Biến thể, Đăng ký, và Vận chuyển

Các truy vấn đọc dữ liệu. Các biến thể đại diện cho các thao tác có thể thay đổi trạng thái phía máy chủ, và các đăng ký đại diện cho một cách nhận cập nhật khi dịch vụ hỗ trợ chúng. Đây là các danh mục thao tác GraphQL, chứ không phải là các đảm bảo về một triển khai cụ thể. Tham khảo thao tác GraphQL mô tả cú pháp và hành vi chọn lựa của chúng.

Nhiều dịch vụ GraphQL sử dụng HTTP cho các truy vấn và biến đổi, nhưng ngôn ngữ GraphQL thì khác biệt so với HTTP. Một yêu cầu có thể mang theo một tài liệu, các biến và một tên hoạt động; dịch vụ quyết định cách mà nó cung cấp sự trao đổi đó. Một đăng ký yêu cầu một phương thức truyền tải và vòng đời hỗ trợ. Đừng giả định rằng một máy chủ hỗ trợ các đăng ký chỉ vì ngôn ngữ GraphQL định nghĩa chúng.

Một phản hồi GraphQL có thể bao gồm dữ liệu và lỗi. Dữ liệu một phần là khả thi khi một số trường được giải quyết trong khi các trường khác thất bại. hướng dẫn thực thi chính thức giải thích đường dẫn trình phân giải đằng sau các trường đã chọn. Mã ứng dụng nên xem xét cả hai phần phản hồi thay vì coi sự tồn tại của dữ liệu là thành công hoàn toàn. Trạng thái và các quy ước lỗi của phương tiện vận chuyển đã được triển khai cũng quan trọng.

GraphQL So Với Giao Diện Hướng REST

Một API hướng REST tổ chức tương tác xung quanh các tài nguyên và biểu diễn dưới một giao diện đồng nhất. GraphQL tổ chức các yêu cầu của khách hàng xung quanh các trường và hoạt động của schema. Cả hai kiểu tổ chức đều có thể được triển khai tốt hoặc xấu. Sự lựa chọn ảnh hưởng đến cách mà khách hàng phát hiện dữ liệu, cách mà máy chủ hạn chế công việc, và cách mà việc lưu cache hoặc thay đổi phiên bản được quản lý; nó không quyết định liệu dữ liệu cơ bản có chính xác hay không.

Một điểm cuối tài nguyên có thể đơn giản để lưu trữ và lý luận khi nhiều khách hàng muốn cùng một đại diện. Việc chọn trường GraphQL giúp khi khách hàng cần các tổ hợp khác nhau của dữ liệu liên quan. Điều này có thể làm cho việc lưu trữ HTTP chia sẻ trở nên ít rõ ràng hơn vì các tài liệu truy vấn khác nhau có thể nhắm đến cùng một điểm cuối. Các nhóm thường thêm các điều khiển cấp hoạt động và bộ nhớ cache ứng dụng để quản lý sự đánh đổi đó.

GraphQL không loại bỏ cần thiết cho phân trang, quy tắc lọc, hoặc ủy quyền. Một truy vấn yêu cầu nhiều đối tượng lồng nhau có thể tốn kém mặc dù chỉ là một yêu cầu HTTP. Đánh giá cả trải nghiệm của khách hàng và chi phí máy chủ với các hoạt động thực tế, bao gồm cả các lựa chọn cố ý lớn hoặc không đúng định dạng. Đếm công việc bên dưới, không chỉ là những lần chuyến mạng.

Tại sao các trang trình duyệt có thể sử dụng GraphQL

Một trang hiện đại có thể tải một shell HTML và sau đó yêu cầu dữ liệu có cấu trúc cho giao diện hiển thị. Lưu lượng mạng của nó có thể bao gồm các thao tác GraphQL mà các trường phản hồi cung cấp thẻ hoặc bảng điều khiển. Trình duyệt Scrapeless Agent chạy trang và JavaScript của nó, làm cho trạng thái đã được kết xuất trở nên quan sát được thông qua tự động hóa trình duyệt. Tài liệu Trình duyệt Agent bao gồm vai trò thực thi trình duyệt đó.

Một yêu cầu GraphQL được quan sát trong công cụ phát triển không nhất thiết là một API công khai được hỗ trợ. Nó có thể phụ thuộc vào cookie, dữ liệu tài khoản riêng tư, hoặc một hợp đồng frontend mà thay đổi mà không có thông báo. hướng dẫn kiểm tra mạng trình duyệt phân biệt quan sát với sự cho phép. Ưu tiên một API đã được tài liệu hóa khi có, và hạn chế phân tích chỉ với dữ liệu công khai hoặc được ủy quyền rõ ràng.

Khi nhiệm vụ là xác minh những gì người dùng thấy, đầu ra trình duyệt đã kết xuất và dữ liệu mạng cơ sở trả lời các câu hỏi khác nhau. Một phản hồi GraphQL có thể chứa các trường mà trang không bao giờ hiển thị; một trang có thể chuyển đổi hoặc bỏ qua chúng. Quyết định đại diện nào mà trường hợp sử dụng của bạn yêu cầu, và ghi lại đủ ngữ cảnh để giải thích tại sao đại diện đó là đúng.

Thiết kế và Tiêu thụ GraphQL An toàn

Trên máy chủ, áp dụng ủy quyền tại ranh giới trường hoặc tài nguyên nơi dữ liệu nhạy cảm có thể được giải quyết. Sự tồn tại của một trường có trong sơ đồ không có nghĩa là mọi người dùng đều có thể đọc giá trị của nó. Ràng buộc các thao tác đắt tiền với độ phức tạp, phân trang hoặc điều khiển độ sâu mà máy chủ hỗ trợ. Quan sát công việc thực tế của bộ giải quyết để một truy vấn có vẻ gọn không thể im lặng mở rộng thành khối lượng công việc lớn phía sau.

Trên client, giữ tài liệu truy vấn gần với các màn hình hoặc thao tác mà sử dụng chúng. Yêu cầu chỉ các trường cần thiết, cung cấp kiểu biến rõ ràng, và xử lý các giá trị có thể null và lỗi không đầy đủ. Các thay đổi đối với sơ đồ nên được xem xét dựa trên các thao tác thực tế của client; việc thêm một trường có thể là an toàn, trong khi việc thay đổi ý nghĩa của một trường đã được thiết lập có thể làm hỏng client ngay cả khi cú pháp vẫn hợp lệ.

Đối với một dịch vụ mà bạn không vận hành, hãy đọc tài liệu công khai của nó thay vì đảo ngược kỹ thuật các thao tác được ủy quyền. Kiểm tra một truy vấn được ủy quyền hẹp và kiểm tra cấu trúc phản hồi của nó. Nếu dịch vụ thay đổi, một lỗi sơ đồ hoặc giá trị null không mong đợi nên dẫn đến việc xem xét hợp đồng, không phải là giả định rằng trang trình duyệt hoặc lưu lượng nội bộ của nó cấp quyền dữ liệu rộng hơn.

Kết luận

GraphQL cho phép các client chọn các trường từ một sơ đồ API có kiểu và nhận kết quả được hình thành bởi những lựa chọn đó. Sơ đồ cải thiện khả năng phát hiện và xác thực, trong khi dịch vụ vẫn sở hữu chi phí thực thi, ủy quyền và chất lượng dữ liệu. Đánh giá GraphQL bằng cách sử dụng các truy vấn client thực tế và hợp đồng máy chủ thực tế.