Các trường hợp sử dụng cho nhiều endpoint tùy chỉnh
GraphQL được thiết kế để hiển thị một endpoint duy nhất để truy vấn dữ liệu. Tuy nhiên, có những tình huống mà thay vào đó việc hiển thị nhiều endpoint tùy chỉnh lại hợp lý hơn, trong đó mỗi endpoint này trình bày một schema được tùy chỉnh riêng. Điều này cho phép chúng ta cung cấp hành vi khác biệt cho các người dùng hoặc ứng dụng khác nhau chỉ đơn giản bằng cách thay đổi endpoint được truy cập.
Việc hiển thị nhiều endpoint trong GraphQL không tương đương với REST. Trong khi REST mỗi endpoint cung cấp quyền truy cập vào một tài nguyên hoặc tập hợp tài nguyên được định sẵn, thì mỗi endpoint GraphQL trong số nhiều endpoint vẫn sẽ cung cấp quyền truy cập vào toàn bộ dữ liệu từ schema của nó, cho phép lấy đúng những gì chúng ta cần. Vì vậy, đây vẫn là hành vi GraphQL thông thường, với phần bổ sung là khả năng truy cập dữ liệu từ các schema khác nhau.
Khả năng này cũng khác với schema stitching hoặc federation, vốn cho phép kết hợp nhiều nguồn dữ liệu thành một đồ thị thống nhất duy nhất. Với nhiều endpoint, chúng ta đang xử lý nhiều schema. Mục đích là xử lý chúng một cách độc lập, chứ không phải như một phần của schema lớn hơn.
Việc hiển thị các schema khác nhau có thể cung cấp quyền truy cập vào nhiều đồ thị độc lập. Người tạo ra GraphQL, Lee Byron, giải thích khi nào điều này có thể hữu ích:
A good example of this might be if you've company is centered around a product and has built a graphql API for that product, and then decides to expand into a new business domain with a new product that doesn't relate to the original product. It could be a burden for both of these unrelated products to share a single API and two separate endpoints with different schema may be more appropriate.
[...] Another example is [...] - you may have a separate internal-only endpoint that is a superset of your external GraphQL API. Facebook uses this pattern and has two endpoints, one internal and one external. The internal one includes internal tools which can interact with product types.
Hãy cùng khám phá thêm một số trường hợp sử dụng khi việc hiển thị nhiều endpoint GraphQL là hợp lý.
Hiển thị riêng biệt các endpoint admin và công khai
Khi chúng ta sử dụng một đồ thị duy nhất cho tất cả dữ liệu trong công ty, chúng ta có thể xác thực ai có quyền truy cập vào các trường khác nhau trong schema GraphQL của mình bằng cách thiết lập các chính sách kiểm soát truy cập. Chẳng hạn, chúng ta có thể cấu hình các trường chỉ có thể truy cập đối với người dùng đã đăng nhập hoặc người dùng có vai trò nhất định.
Tuy nhiên, khi có các trường chứa thông tin nhạy cảm hoặc bí mật, đến mức không có trường hợp nào những trường này nên có thể truy cập được với các tác nhân không mong muốn, thì tốt hơn chúng ta không nên hiển thị những trường này trong schema công khai ngay từ đầu, mà chỉ trong schema riêng tư mà chỉ nhóm có quyền truy cập. Chiến lược này sẽ bảo vệ dữ liệu riêng tư của chúng ta khỏi các vấn đề không mong muốn, chẳng hạn như lỗi phần mềm và sự bất cẩn khi cấu hình schema, và thậm chí tăng cường bảo mật bằng cách chỉ cho phép khách truy cập từ một số IP nhất định truy cập endpoint riêng tư.
Do đó, chúng ta có thể tạo hai schema riêng biệt, schema Admin và schema Public, và hiển thị chúng lần lượt dưới các endpoint /graphql/admin (và hạn chế quyền truy cập vào đó cho khách truy cập từ một IP nhất định) và /graphql/public (có thể truy cập với mọi người).
Hạn chế quyền truy cập vào thông tin riêng tư theo cách an toàn hơn
Phần này là sự tổng quát hóa của phần trước: không chỉ là công khai so với admin, mà là bất kỳ tình huống nào trong đó một tập hợp người dùng chắc chắn không được phép truy cập thông tin từ một tập hợp người dùng khác.
Chẳng hạn, bất cứ khi nào chúng ta cần tạo các schema tùy chỉnh cho các khách hàng khác nhau, chúng ta có thể hiển thị một endpoint tùy chỉnh cho mỗi người trong số họ (/graphql/some-client, /graphql/another-client, v.v.), điều này có thể an toàn hơn là cho họ quyền truy cập vào cùng một schema thống nhất và xác thực họ thông qua kiểm soát truy cập.
Cung cấp hành vi khác nhau cho các ứng dụng khác nhau
Chúng ta có thể cấp hành vi khác nhau cho các ứng dụng khác nhau truy cập vào cùng một nguồn dữ liệu.
Chẳng hạn, Reddit tạo ra phản hồi khác nhau nếu được truy cập từ trình duyệt máy tính để bàn hoặc từ trình duyệt di động. Từ trình duyệt máy tính để bàn, dù chúng ta có đăng nhập hay không, chúng ta đều có thể trực tiếp xem nội dung:

Khi truy cập từ thiết bị di động, chúng ta phải đăng nhập để truy cập nội dung và được khuyến khích sử dụng ứng dụng thay thế:

Hành vi khác nhau này có thể được cung cấp bằng cách tạo hai schema, schema Desktop và schema Mobile, và hiển thị chúng lần lượt dưới /graphql/desktop và /graphql/mobile.
Tạo một trang web bằng nhiều ngôn ngữ khác nhau
Nếu chúng ta muốn tạo cùng một trang web bằng nhiều ngôn ngữ khác nhau, chúng ta có thể để mã ngôn ngữ đã là một phần của cấu trúc endpoint tùy chỉnh, chẳng hạn như /graphql/en cho tiếng Anh và /graphql/fr cho tiếng Pháp. Sau đó, máy chủ GraphQL có thể truy xuất thông tin này và dịch dữ liệu sang ngôn ngữ mong muốn.
Cuối cùng, chúng ta trỏ đến mỗi endpoint này trong trình tạo trang web tĩnh để tạo ra trang web bằng ngôn ngữ này hay ngôn ngữ khác:

Kiểm thử schema được nâng cấp trước khi phát hành cho môi trường sản xuất
Nếu chúng ta muốn nâng cấp schema GraphQL của mình và cho một tập hợp người dùng kiểm thử trước, chúng ta có thể hiển thị schema mới này thông qua endpoint /graphql/upcoming. Hơn nữa, chúng ta cũng có thể hiển thị endpoint /graphql/bleeding-edge, liên tục triển khai schema từ DEV.
Hỗ trợ phương pháp BfF
Backend-for-Frontends (viết tắt là BfF) là một phương pháp để tạo ra các API khác nhau cho các client khác nhau, trong đó mỗi client "sở hữu" API của mình, cho phép nó tạo ra phiên bản tối ưu nhất dựa trên các yêu cầu riêng của mình.
Trong mô hình này, một BfF tùy chỉnh đóng vai trò trung gian giữa các dịch vụ back-end và client của nó:

Mô hình này có thể được đáp ứng trong GraphQL bằng cách để tất cả các BfF được triển khai trong một máy chủ GraphQL duy nhất với nhiều endpoint, với mỗi endpoint xử lý một BfF/client cụ thể (chẳng hạn như /graphql/mobile và /graphql/web):
