內(nèi)容主要摘取并翻譯自How to GraphQL，翻譯的時(shí)候做了適當(dāng)?shù)暮?jiǎn)化

GraphQL 是由Facebook開(kāi)發(fā)的一個(gè)開(kāi)源項(xiàng)目，是一個(gè)比REST更加靈活高效的新的API標(biāo)準(zhǔn)

API是軟件開(kāi)發(fā)中一個(gè)普遍存在的要素. 簡(jiǎn)而言之，API定義了客戶端如何從服務(wù)端加載數(shù)據(jù).

GraphQL的核心思想就是允許客戶端去準(zhǔn)確聲明它所需要的數(shù)據(jù)，傳統(tǒng)的客戶端可能會(huì)請(qǐng)求多個(gè)端點(diǎn)，每個(gè)端點(diǎn)返回固定的數(shù)據(jù)結(jié)構(gòu)，而GraphQL的服務(wù)端只會(huì)暴露一個(gè)端點(diǎn)出來(lái)，并且返回的剛好就是客戶端需要的數(shù)據(jù)

GraphQL - 一個(gè)用于API的查詢語(yǔ)言

現(xiàn)在絕大多數(shù)應(yīng)用都需要從服務(wù)端請(qǐng)求數(shù)據(jù)，這個(gè)數(shù)據(jù)通常是儲(chǔ)存在數(shù)據(jù)庫(kù)中的。API負(fù)責(zé)為存儲(chǔ)的數(shù)據(jù)提供適合應(yīng)用程序需求的接口。

GraphQL經(jīng)常會(huì)被誤解成數(shù)據(jù)庫(kù)技術(shù)，這個(gè)觀念其實(shí)是不對(duì)的，GraphQL是一個(gè)用于API的查詢語(yǔ)言 - 而不是數(shù)據(jù)庫(kù)。在這個(gè)層面來(lái)說(shuō)，任何使用了API的地方都可以使用GraphQL，而不用去在乎數(shù)據(jù)庫(kù)用的是什么

比REST更高效的替代方案

?? 了解更多使用GraphQL的理由可以看看 這篇 文章

REST 是一個(gè)常用的從服務(wù)端暴露數(shù)據(jù)的方法. 當(dāng)REST這個(gè)概念被提出來(lái)的時(shí)候，客戶端應(yīng)用還都是一些相對(duì)簡(jiǎn)單的應(yīng)用，遠(yuǎn)不及當(dāng)今的發(fā)展速度，所以那個(gè)時(shí)候REST還是適合很多應(yīng)用的. 然而，API在過(guò)去幾年中發(fā)生了根本性的變化。特別是，有三個(gè)因素一直在挑戰(zhàn)API的設(shè)計(jì)方式：

1. 移動(dòng)端的使用增加需要更有效的數(shù)據(jù)加載

移動(dòng)端設(shè)備的使用增加，低功耗的設(shè)備以及不穩(wěn)定的網(wǎng)絡(luò)是Facebook開(kāi)發(fā)GraphQL的起因。GraphQL最大限度地減少了需要通過(guò)網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，從而大大改善了在這些條件下運(yùn)行的應(yīng)用程序。

2. 各種不同的前端框架和平臺(tái)

運(yùn)行客戶端應(yīng)用程序的前端框架和平臺(tái)的差異使得構(gòu)建和維護(hù)一個(gè)滿足所有需求的API變得困難。使用GraphQL，每個(gè)客戶端都可以精確訪問(wèn)所需的數(shù)據(jù)。

3. 快速開(kāi)發(fā)和期望快速功能開(kāi)發(fā)

許多公司都希望可以做到持續(xù)部署，快速迭代和更新產(chǎn)品。使用REST API，要滿足客戶端的需求變更的時(shí)候，往往會(huì)需要服務(wù)端配合改動(dòng)提供數(shù)據(jù)的方法，這阻礙了快速開(kāi)發(fā)實(shí)踐和產(chǎn)品迭代。