什麼是 GraphQL？
GraphQL 是一種開源的 API 查詢語言，最初由 Facebook 於 2012 年開發，並於 2015 年公開發佈。它提供了一種靈活且高效的替代方案，與傳統的 REST API 相比，允許客戶端僅請求所需的特定數據，解決了 REST API 中常見的過度獲取和不足獲取問題。
GraphQL 日益受到歡迎的原因之一是其以客戶端為驅動的特性。這使其特別適合於對性能、可擴展性和無縫用戶體驗要求高的現代應用。GraphQL 使客戶端能夠將多個資源組合成單一請求，減少網絡流量，並成為帶寬有限或前端需求複雜的移動應用的絕佳解決方案。
像 GitHub、Twitter、Indeed 和 Shopify 等主要公司已經採用了 GraphQL，突顯了它在簡化 API 開發和改善客戶端-服務器互動方面的潛力。
GraphQL 接口
在 GraphQL 中，接口的功能類似於面向對象編程中的接口。這是一種抽象類型，定義了一組多個對象類型可以實現的共同字段。這確保了客戶端可以自信地查詢不同類型之間的這些共同字段。
type Query {
findVehicles(): [Vehicle!]!
}
interface Vehicle {
id: ID!
name: String!
model: String
}
type Car implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Car
fuelType: String!
}
type Bicycle implements Vehicle {
id: ID!
name: String!
model: String
# Specific to Bicycle
gearCount: Int!
isElectric: Boolean!
}
GraphQL 客戶端查詢：
query findVehicles() {
findVehicles() {
vehicle {
id,
name,
model,
... on Car {
fuelType
}
... on Bicycle {
gearCount,
isElectric
}
}
}
}
在這個例子中，像 id、name 和 model 這些常見欄位在實作 Vehicle 介面的所有物件類型中都是可用的。然而，類型特定的欄位，例如 Car 的 fuelType 和 Bicycle 的 gearCount 及 isElectric 可以透過片段進行查詢。
如果客戶端只需要常見欄位，他們可以省略片段：
query findCars() {
findCars() {
car {
id,
name,
model
}
}
}
使用介面的好處
- 代碼重用性：常見欄位可以在介面中定義並在多個類型間共享，減少冗餘。
- 簡化客戶端邏輯：客戶端不需要對物件類型進行條件檢查。他們可以請求確切的類型並自信地處理回應。
- 架構可擴展性：添加新的常見欄位變得更容易，因為它只需要在介面中定義。
- 強制結構：介面強制所有實作類型之間共享結構，確保一致性（例如，所有車輛必須具有
id、name和model）。 - 統一查詢：客戶端可以查詢單一介面，而不是單獨查詢不同類型，從而從所有實作類型中檢索數據。
- 改善文檔：通過介面定義共同行為，API 使用者更容易理解和處理相關類型。
GraphQL 聯合
在 GraphQL 中，聯合是一種抽象類型，允許客戶端通過單一字段查詢在某些方面相關的多個對象類型。與接口不同，聯合不要求成員類型共享共同字段。這使得聯合非常適合處理那些相關類型具有不同結構但需要一起查詢的情況。
type Query {
getPurchaseItems(): [PurchaseItem!]!
}
union PurchaseItem = Product | Service | Subscription
type Product {
id: ID!
productName: String!
price: Float!
}
type Service {
id: ID!
serviceName: String
duration: Float
}
type Subscription {
id: ID!
planName: String
billingCycle: String
}
GraphQL 客戶端查詢:
query getPurchaseItems() {
getPurchaseItems() {
purchaseItems {
... on Product {
id
productName
price
}
... on Service {
id
serviceName
duration
}
... on Subscription {
id
planName
billingCycle
}
}
}
}
在這個例子中，Product、Service 和 Subscription 都是屬於 PurchaseItem 聯合的獨立類型。客戶端可以在單一查詢中使用片段來查詢這三種類型，即使它們不共享任何字段。
關於聯合的重要說明，聯合類型的成員類型必須都是對象基類型；標量、接口和聯合類型不得是聯合的成員類型。同樣，包裝類型也不得是聯合的成員類型。
使用聯合的好處
- 靈活的分組：聯合允許查詢不共享任何共同字段的相關類型，否則這將變得繁瑣。
- 簡化的錯誤處理：客戶端可以使用片段查詢特定類型，減少客戶端需要的複雜條件邏輯。
- 異構數據處理：單一查詢可以從多個類型中檢索數據，簡化了對各種數據結構的處理。
- 對於錯誤響應的實用性：當你想將成功響應和錯誤詳情合併為一種響應類型時，聯合特別有用，這樣客戶端能夠高效處理它們。
總結
：GraphQL 接口和聯合提供了強大的方式來構建你的 GraphQL 架構，實現靈活性並簡化客戶端與服務器之間的互動。接口允許跨類型共享字段，促進代碼重用和更簡單的架構擴展。而聯合則提供了一種方法，可以將不同的類型一起查詢，而不需要共同字段。
Source:
https://dzone.com/articles/a-beginners-guide-to-graphql-interfaces-and-unions