使用GraphQL的5個(gè)理由

原文:Top 5 Reasons to Use GraphQL

目的

GraphQL已成為新的API開發(fā)標(biāo)準(zhǔn)。

為何僅用兩年多時(shí)間，GraphQL就已走在了API開發(fā)的前沿？為何開發(fā)人員喜歡GraphQL快速開發(fā)?本文給出幾個(gè)理由。

1) GraphQL API 有強(qiáng)類型 schema

對大多數(shù)API而言，最大的問題在于缺少強(qiáng)類型約束。常見場景為，后端API更新了，但文檔沒跟上，你沒法知道新的API是干什么的，怎么用，這應(yīng)該是前后端掐架的原因之一。

GraphQL schema 是每個(gè)GraphQL API的基礎(chǔ)，它清晰的定義了每個(gè)API支持的操作，包括輸入的參數(shù)和返回的內(nèi)容。

GraphQL schema是一個(gè)約定，用于指明API的功能。

GraphQL schema是強(qiáng)類型的，可使用SDL(GraphQL Schema Definition Language)來定義。相對而言，強(qiáng)類型系統(tǒng)使開發(fā)人員自行車換摩托。比如，可以使用構(gòu)建工具驗(yàn)證API請求，編譯時(shí)檢查API調(diào)用可能發(fā)生的錯(cuò)誤，甚至可以在代碼編輯器中自動(dòng)完成API操作。

schema帶來的另一個(gè)好處是，不用再去編寫API文檔——因?yàn)楦鶕?jù)schema自動(dòng)生成了，這改變了API開發(fā)的玩法。

2) 按需獲取

我們經(jīng)常談GraphQL的主要優(yōu)點(diǎn)——前端可以從API獲取想要的數(shù)據(jù)，不必依賴REST端返回的固定數(shù)據(jù)結(jié)構(gòu)。

如此，解決了傳統(tǒng)REST API的兩個(gè)典型問題：Overfetching和Underfetching。

使用GraphQL，前端自己決定返回的數(shù)據(jù)及結(jié)構(gòu)。

Overfetching

Overfetching意味著前端得到了實(shí)際不需要的數(shù)據(jù)，這可能會造成性能和帶寬浪費(fèi)。

栗子：個(gè)人資料頁面需要呈現(xiàn)用戶姓名和生日；提供用戶信息的API(如/users/id)還會返回用戶的地址和賬單信息，但這在個(gè)人資料頁面沒有用，也沒必要。

Underfetching

Underfetching與Overfetching想反，API返回中缺少足夠的數(shù)據(jù)，這意味著前端需要請求額外的API得到需要的數(shù)據(jù)。

最壞的場景下，不足的結(jié)果會導(dǎo)致臭名昭著的N+1請求問題：獲取數(shù)據(jù)列表，而沒有API能夠滿足列表字段要求，不得不對每行數(shù)據(jù)發(fā)起一次請求，以獲取所需數(shù)據(jù)。

栗子：假設(shè)我們在搗鼓一個(gè)博客應(yīng)用。顯示 user列表，除user本身信息外，還要顯示每個(gè)user最近一篇文章的title。然而，調(diào)用/users/僅得到user集合，不得不對每個(gè)user調(diào)用/users/<id>/articles獲取其最新文章。

說明：當(dāng)然你可以再寫一個(gè)API來滿足特殊場景，如/users/lastarticles/來滿足上面的需求，但需要編寫后端相關(guān)代碼，調(diào)試和部署，加班....有這時(shí)間何不去陪家人孩子。

3) GraphQL支持快速產(chǎn)品開發(fā)

GraphQL使前端開發(fā)人員輕松，感謝GraphQL的前端庫(Apollo、Relay或Urql)，前端可以用如緩存、實(shí)時(shí)更新UI等功能。

前端開發(fā)人員生產(chǎn)力提高，產(chǎn)品開發(fā)速度加快，無論UI如何變后端不用變。

構(gòu)建GraphQL API的過程大多圍繞GraphQL scheme。由此，經(jīng)常聽到 schema-driven development(SDD)，這只是指一個(gè)過程，功能在schema中定義，在resolver(解析器)中實(shí)現(xiàn)。

有了像GraphQL Faker這樣的工具，前端開發(fā)可以在schema定義后開始。GraphQL Faker模擬整個(gè)GraphQL API(依賴于定義的schema)，因此前后端可以獨(dú)立工作。

4) Composing GraphQL API

schema拼接(stitching)是GraphQL中的新概念之一，簡而言之，可以組合和連接多個(gè)GraphQL API，合并為一個(gè)。與React組件概念類似，一個(gè)GraphQL API可以由多個(gè)GraphQL API構(gòu)成。

這對前端開發(fā)非常有用，不然，需要與多個(gè)GraphQL端點(diǎn)通信(通常在微服務(wù)架構(gòu)或與第三方API集成時(shí))。由于schema拼接，前端只需要處理單個(gè)API端點(diǎn)，而協(xié)調(diào)與各種服務(wù)通信的復(fù)雜性從前端隱藏。

5) 豐富的開源生態(tài)和牛逼閃閃的社區(qū)

自Facebook正式發(fā)布GraphQL以來，僅兩年多時(shí)間，整個(gè)GraphQL生態(tài)系統(tǒng)的成熟程度難以置信。

剛發(fā)布時(shí)，開發(fā)人員使用GraphQL的唯一工具是graphql-js參考實(shí)現(xiàn)——一個(gè)Express.js中間件和GraphQL client Relay。

現(xiàn)在，GraphQL規(guī)范的參考實(shí)現(xiàn)有多種語言可以選擇，并有大量的GraphQL客戶端。此外許多工具提供了無縫的工作流程，并在構(gòu)建GraphQL API時(shí)提供爽爽的開發(fā)體驗(yàn)，如：Primsa、GraphQL Faker、GraphQL Playground、graphql-config等。

GraphQL社區(qū)日益壯大，越來越多的公司將其用之于產(chǎn)品。


參考

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務(wù)發(fā)現(xiàn)，斷路器，智...
    卡卡羅2017閱讀 136,569評論 19贊 139
  • 一.時(shí)間： 2017年3月1日-2017年5月31日 二.目標(biāo): 為公司在名錶銷售，個(gè)人訂製珠寶銷售創(chuàng)造，月營利港...
    andychan1106閱讀 224評論 2贊 4
  • 2017.11.05周日，晴 今天晚上我和兒子到都市星聯(lián)大酒店參加由夏爾美術(shù)主辦的家庭教育課堂。我們到達(dá)目的地...
    王瀚霆媽媽閱讀 302評論 0贊 0
  • 今天，家人在一起喝下午茶 、大家難得在一起，而我一人滔滔不絕，時(shí)而還說老公在一些決策錯(cuò)誤，自己當(dāng)時(shí)完全失去覺察。等...
    夏虹正如閱讀 200評論 1贊 1
  • 因?yàn)橄挛缫D(zhuǎn)戰(zhàn)凱恩斯，所以上午司機(jī)兼導(dǎo)游老沈帶我們參觀了墨爾本有名的科林大街，這里是墨爾本的金融聚集地，繁華而有序...
    貓司令的碎碎念閱讀 877評論 0贊 2

友情鏈接更多精彩內(nèi)容