原文:Top 5 Reasons to Use GraphQL
目的
GraphQL已成為新的API開發(fā)標(biāo)準(zhǔn)。
為何僅用兩年多時間，GraphQL就已走在了API開發(fā)的前沿？為何開發(fā)人員喜歡GraphQL快速開發(fā)?本文給出幾個理由。
1) GraphQL API 有強類型 schema
對大多數(shù)API而言，最大的問題在于缺少強類型約束。常見場景為，后端API更新了，但文檔沒跟上，你沒法知道新的API是干什么的，怎么用，這應(yīng)該是前后端掐架的原因之一。
GraphQL schema 是每個GraphQL API的基礎(chǔ)，它清晰的定義了每個API支持的操作，包括輸入的參數(shù)和返回的內(nèi)容。
GraphQL schema是一個約定，用于指明API的功能。
GraphQL schema是強類型的，可使用SDL(GraphQL Schema Definition Language)來定義。相對而言，強類型系統(tǒng)使開發(fā)人員自行車換摩托。比如，可以使用構(gòu)建工具驗證API請求，編譯時檢查API調(diào)用可能發(fā)生的錯誤，甚至可以在代碼編輯器中自動完成API操作。
schema帶來的另一個好處是，不用再去編寫API文檔——因為根據(jù)schema自動生成了，這改變了API開發(fā)的玩法。
2) 按需獲取
我們經(jīng)常談GraphQL的主要優(yōu)點——前端可以從API獲取想要的數(shù)據(jù)，不必依賴REST端返回的固定數(shù)據(jù)結(jié)構(gòu)。
如此，解決了傳統(tǒng)REST API的兩個典型問題：Overfetching和Underfetching。
使用GraphQL，前端自己決定返回的數(shù)據(jù)及結(jié)構(gòu)。
Overfetching
Overfetching意味著前端得到了實際不需要的數(shù)據(jù)，這可能會造成性能和帶寬浪費。
栗子：個人資料頁面需要呈現(xiàn)用戶姓名和生日；提供用戶信息的API(如/users/id)還會返回用戶的地址和賬單信息，但這在個人資料頁面沒有用，也沒必要。
Underfetching
Underfetching與Overfetching想反，API返回中缺少足夠的數(shù)據(jù)，這意味著前端需要請求額外的API得到需要的數(shù)據(jù)。
最壞的場景下，不足的結(jié)果會導(dǎo)致臭名昭著的N+1請求問題：獲取數(shù)據(jù)列表，而沒有API能夠滿足列表字段要求，不得不對每行數(shù)據(jù)發(fā)起一次請求，以獲取所需數(shù)據(jù)。
栗子：假設(shè)我們在搗鼓一個博客應(yīng)用。顯示 user列表，除user本身信息外，還要顯示每個user最近一篇文章的title。然而，調(diào)用/users/僅得到user集合，不得不對每個user調(diào)用/users/<id>/articles獲取其最新文章。
說明：當(dāng)然你可以再寫一個API來滿足特殊場景，如/users/lastarticles/來滿足上面的需求，但需要編寫后端相關(guān)代碼，調(diào)試和部署，加班....有這時間何不去陪家人孩子。
3) GraphQL支持快速產(chǎn)品開發(fā)
GraphQL使前端開發(fā)人員輕松，感謝GraphQL的前端庫(Apollo、Relay或Urql)，前端可以用如緩存、實時更新UI等功能。
前端開發(fā)人員生產(chǎn)力提高，產(chǎn)品開發(fā)速度加快，無論UI如何變后端不用變。
構(gòu)建GraphQL API的過程大多圍繞GraphQL scheme。由此，經(jīng)常聽到 schema-driven development(SDD)，這只是指一個過程，功能在schema中定義，在resolver(解析器)中實現(xiàn)。
有了像GraphQL Faker這樣的工具，前端開發(fā)可以在schema定義后開始。GraphQL Faker模擬整個GraphQL API(依賴于定義的schema)，因此前后端可以獨立工作。
4) Composing GraphQL API
schema拼接(stitching)是GraphQL中的新概念之一，簡而言之，可以組合和連接多個GraphQL API，合并為一個。與React組件概念類似，一個GraphQL API可以由多個GraphQL API構(gòu)成。
這對前端開發(fā)非常有用，不然，需要與多個GraphQL端點通信(通常在微服務(wù)架構(gòu)或與第三方API集成時)。由于schema拼接，前端只需要處理單個API端點，而協(xié)調(diào)與各種服務(wù)通信的復(fù)雜性從前端隱藏。
5) 豐富的開源生態(tài)和牛逼閃閃的社區(qū)
自Facebook正式發(fā)布GraphQL以來，僅兩年多時間，整個GraphQL生態(tài)系統(tǒng)的成熟程度難以置信。
剛發(fā)布時，開發(fā)人員使用GraphQL的唯一工具是graphql-js參考實現(xiàn)——一個Express.js中間件和GraphQL client Relay。
現(xiàn)在，GraphQL規(guī)范的參考實現(xiàn)有多種語言可以選擇，并有大量的GraphQL客戶端。此外許多工具提供了無縫的工作流程，并在構(gòu)建GraphQL API時提供爽爽的開發(fā)體驗，如：Primsa、GraphQL Faker、GraphQL Playground、graphql-config等。
GraphQL社區(qū)日益壯大，越來越多的公司將其用之于產(chǎn)品。
參考
- GraphQL 中文文檔
- How to build a GraphQL Server with graphql-yoga
- How to GraphQL: The fullstack GraphQL tutorial
-
GraphQL boilerplates: Starter kits for GraphQL projects with Node, TypeScript, React, Vue,…
How to GraphQL
GraphQL規(guī)范
