[譯] 怎樣使用GraphQL - 進階 - 1.客戶端

英文原版地址：https://www.howtographql.com/...

在前端使用GraphQL API，對於抽象和實現基礎功能，是一個好機會。讓咱們考慮你在應用中可能想要的一些「基礎」功能：

• 直接發送查詢和mutation而不用構建HTTP請求
• 視圖層集成
• 緩存
• 基於schema去校驗和優化查詢

固然，沒有什麼能夠阻止你僅使用HTTP來獲取你的數據，而後本身逐個處理，直到正確的信息最終顯示在UI上。 可是GraphQL提供了避免大量手動勞動的能力，讓你專一於應用的核心部分！ 在下文中，咱們將更詳細地討論這些能力。

目前有兩個主要的GraphQL客戶端庫。 第一個是Apollo客戶端，這是一個社區支持的項目，旨在爲全部主要開發平臺構建強大而靈活的GraphQL客戶端。 第二個被稱爲Relay，它是Facebook官方的GraphQL客戶端，它大大優化了性能，但只能在web上可用。

直接發送查詢和mutation

GraphQL的主要優勢是它容許您以聲明的方式獲取和更新數據。換句話說，咱們在API抽象層面更進一步，沒必要再本身處理低級網絡任務。

之前你使用純HTTP（如JavaScript中的fetch或iOS中的NSURLSession）從API加載數據。使用GraphQL後，全部操做都將寫入一個查詢，聲明瞭數據需求後，讓系統負責發送請求並處理響應。這正是GraphQL客戶端要作的。

視圖層集成和UI更新

在服務端的響應，被GraphQL客戶端接收到以後，數據須要最終展示在UI中。根據開發的平臺和選用的框架不一樣，UI更新也將會有不一樣的方式。

以React爲例，GraphQL客戶端使用高階組件的理念來獲取所需的數據，並使其在組件的porps中可用。通常來講，GraphQL的聲明式特性與函數式反應型編程（FRP）結合的很好。二者能夠造成強大的組合，其中視圖只是聲明其數據依賴，UI則與選擇的FRP層鏈接。

緩存查詢結果：概念和策略

在大多數應用中，你須要緩存以前從服務器獲取的數據。這對於提供流暢的用戶體驗和維護好用戶數據相當重要。

一般，當緩存數據時，直覺是將遠程獲取的信息放入本地存儲中，以便稍後檢索。使用GraphQL，直覺上的辦法就是將GraphQL查詢的結果簡單地放入存儲，而且只要再次執行徹底相同的查詢，就返回先前存儲的數據。事實證實，這種方式對於大多數應用來講是很是低效的。

更有效的方式是提早規範化數據。這意味着（多是）嵌套的查詢結果會變得平坦，而且存儲的是，可使用全局惟一ID來查詢的單個記錄內容。若是想了解更多關於這一點的信息，Apollo博客對這個內容作了很好的介紹。

構建時的驗證和優化

因爲視圖（schema）包含有關客戶端可使用GraphQL API的全部信息，所以，客戶端在構建時驗證查詢就變得很方便。

當構建環境能夠訪問schema時，它能夠基本解析位於項目中的全部GraphQL代碼，並將其與schema中的信息進行比較。這樣就能夠捕獲打字錯誤和其餘錯誤，避免一些嚴重後果。

結合視圖層和數據層

GraphQL的一個強大的理念是，它容許你並行地處理UI代碼和數據需求。界面和數據的緊密結合，大大提升了開發人員的體驗。不用再去考慮，如何在UI中恰當的填充數據。

結合帶來的優點大小，取決於您正在開發的平臺。例如在Javascript應用中，能夠將數據依賴和UI代碼放在同一個文件中。在Xcode中，Assistant Editor可用於同時處理視圖控制器和graphql代碼。