GraphQL是什么

? ? GraphQL是一種新的API標準，它提供了一種更高效、強大和靈活的數(shù)據(jù)提供方式。它是由Facebook開發(fā)和開源，目前由來自世界各地的大公司和個人維護。GraphQL本質(zhì)上是一種基于api的查詢語言，現(xiàn)在大多數(shù)應(yīng)用程序都需要從服務(wù)器中獲取數(shù)據(jù)，這些數(shù)據(jù)存儲可能存儲在數(shù)據(jù)庫中，API的職責是提供與應(yīng)用程序需求相匹配的存儲數(shù)據(jù)的接口。有的人經(jīng)常把GraphQL和數(shù)據(jù)庫技術(shù)相混淆，這是一個誤解，GraphQL是api的查詢語言，而不是數(shù)據(jù)庫。從這個意義上說，它是數(shù)據(jù)庫無關(guān)的，而且可以在使用API的任何環(huán)境中有效使用，我們可以理解為GraphQL是基于API之上的一層封裝，目的是為了更好，更靈活的適用于業(yè)務(wù)的需求變化。

GraphQL出現(xiàn)的歷史背景

? ? 當提起API設(shè)計的時候，大家通常會想到SOAP，RESTful等設(shè)計方式，從2000年RESTful的理論被提出的時候，在業(yè)界引起了很大反響，因為這種設(shè)計理念更易于用戶的使用，所以便很快的被大家所接受。我們知道REST是一種從服務(wù)器公開數(shù)據(jù)的流行方式。當REST的概念被提及出來時，客戶端應(yīng)用程序?qū)?shù)據(jù)的需求相對簡單，而開發(fā)的速度并沒有達到今天的水平。因此REST對于許多應(yīng)用程序來說是非常適合的。然而在業(yè)務(wù)越發(fā)復雜，客戶對系統(tǒng)的擴展性有了更高的要求時，API環(huán)境發(fā)生了巨大的變化。特別是從下面三個方面在挑戰(zhàn)api設(shè)計的方式:
1.移動端用戶的爆發(fā)式增長需要更高效的數(shù)據(jù)加載

Facebook開發(fā)GraphQL的最初原因是移動用戶的增加、低功耗設(shè)備和松散的網(wǎng)絡(luò)。GraphQL最小化了需要網(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)量，從而極大地改善了在這些條件下運行的應(yīng)用程序。

2.各種不同的前端框架和平臺

前端框架和平臺運行客戶端應(yīng)用程序的異構(gòu)環(huán)境使得我們在構(gòu)建和維護一個符合所有需求的API變得困難，使用GraphQL每個客戶機都可以精確地訪問它需要的數(shù)據(jù)。

3.在不同前端框架，不同平臺下想要加快產(chǎn)品快速開發(fā)變的越來越難

持續(xù)部署已經(jīng)成為許多公司的標準，快速的迭代和頻繁的產(chǎn)品更新是必不可少的。對于REST api，服務(wù)器公開數(shù)據(jù)的方式常常需要修改，以滿足客戶端的特定需求和設(shè)計更改。這阻礙了快速開發(fā)實踐和產(chǎn)品迭代。

? ? GraphQL的出現(xiàn)不僅僅是針對開發(fā)人員的，Facebook在2012年開始在其native mobile apps中使用GraphQL。但有趣的是GraphQL大部分都是在web技術(shù)的背景下使用的，并且在native mobile 領(lǐng)域中只得到很少的支持。 Facebook第一次公開談?wù)揋raphQL是在宣布開源計劃后不久的2015年React峰會的時候。因為Facebook總是在React的背景下談GraphQL，所以對于沒有React經(jīng)驗的開發(fā)人員來說，要理解GraphQL并不是一種僅限于React使用的技術(shù)可能還需要一段時間。即便是在這樣的背景下誕生的GraphQL依然是一個快速增長的社區(qū) ,事實上GraphQL是一種技術(shù)，可以在客戶端與API通信的任何地方使用。有趣的是Netflix和Coursera等其他公司都在研究類似的想法以提高API的交互效率。Coursera設(shè)想了一種類似的技術(shù)，可以讓客戶指定其數(shù)據(jù)需求，而Netflix甚至將其解決方案稱為Falcor。在GraphQL被開源之后，Coursera完全停止了他們在Falcor上的努力，并轉(zhuǎn)到了GraphQL的學習上。目前已經(jīng)有很多的公司在使用GraphQL（https://graphql.org/users/）。

GraphQL和RESTful的區(qū)別

前面提到GraphQL可以理解為基于RESTful的一種封裝，目的在于構(gòu)建使Client更加易用的服務(wù)，可以說GraphQL是更好的RESTful設(shè)計。在過去的十多年中，REST已經(jīng)成為設(shè)計web api的標準(雖然只是一個模糊的標準)。它提供了一些很棒的想法，比如無狀態(tài)服務(wù)器和結(jié)構(gòu)化的資源訪問。然而REST api表現(xiàn)得過于僵化，無法跟上訪問它們的客戶的快速變化的需求。 GraphQL的開發(fā)是為了應(yīng)付更多的靈活性和效率，它解決了與REST api交互時開發(fā)人員所經(jīng)歷的許多缺點和低效之處。 為了說明在從API獲取數(shù)據(jù)時REST和GraphQL之間的主要區(qū)別，讓我們考慮一個簡單的示例場景：在blog應(yīng)用程序中，應(yīng)用程序需要顯示特定用戶的文章的標題。同一屏幕還顯示該用戶最后3個關(guān)注者的名稱。REST和GraphQL如何解決這種情況?

?使用REST API來現(xiàn)實時，我們通常可以通過訪問多次請求來收集數(shù)據(jù)。比如在這個示例中，我們可以通過下面的三步來實現(xiàn)：

?1. 通過 /user/<id>獲取初始用戶數(shù)據(jù)

?2. 通過/user/<id>/posts 返回用戶的所有帖子

?3. 請求/user/<id>/followers，返回每個用戶的關(guān)注者列表

調(diào)用關(guān)系如下圖所示：

?

如果用GraphQL的話，我們只需要一次請求就可以完成上述的需求

在GraphQL的世界里我們不用多取數(shù)據(jù)，也不用擔心數(shù)據(jù)取少了，我們只需要按需獲取即可。

REST最常見的問題之一是API的返回數(shù)據(jù)過多或者過少，這是因為客戶端下載數(shù)據(jù)的唯一方法是通過訪問返回固定數(shù)據(jù)結(jié)構(gòu)的endpoint，這就會導致我們設(shè)計API非常困難，因為它既要能夠為客戶提供精確的數(shù)據(jù)需求，又需要滿足不同調(diào)用者的需求，這本身就是相互矛盾的。GraphQL的發(fā)明者Lee Byron提出了一個很重要的概念：?“用圖形來思考，而不是endpoint”

通過上述直觀展示我們可以得出一下幾點：

1. 獲取了許多多余的數(shù)據(jù)

通常情況下我們在調(diào)用一個通用API接口時，客戶端獲取的信息比應(yīng)用程序中實際需要的要多。例如UI需要顯示一個用戶列表，而實際上只需要使用他們的名字。在REST API中通常會調(diào)用?/user?這個endpoint，并接收一個帶有用戶數(shù)據(jù)的JSON數(shù)組。但是這個響應(yīng)可能包含更多關(guān)于返回的用戶的信息，例如他們的生日或地址，而這些信息對客戶來說是無用的，因為它只需要顯示用戶的名字。

2. 獲取的數(shù)據(jù)少于Client所需要的數(shù)據(jù)

一般來說數(shù)據(jù)獲取不足意味著某個特定的endpoint 沒有提供客戶端需要的足夠信息，客戶端將需要額外的請求來獲取它所需要的一切。這可能會升級到客戶端需要首先獲取列表信息，然后需要對單條數(shù)據(jù)添加一個額外的請求以獲取其他所需的數(shù)據(jù)，例如考慮其他Client 也需要顯示每個用戶的最后三個關(guān)注者，該API提供了額外的endpoint??/user/<userid>/followers，為了能夠顯示所需的信息，Client 必須向?/users?endpoint 發(fā)出一個請求，然后點擊/user/<user-id>/follwers?endpoint 來獲取單個用戶的follwers信息。

3.?前端的快速產(chǎn)品迭代對API有很大的挑戰(zhàn)

REST api的一個常見模式是根據(jù)你在應(yīng)用程序內(nèi)部的展現(xiàn)邏輯來構(gòu)造endpoint，這很方便，因為它允許客戶端通過訪問相應(yīng)的endpoint獲取特定視圖的所有所需信息。 這種方法的主要缺點是它不允許前端的快速迭代。對于UI所做的每一個更改，現(xiàn)在都存在比以前更多(或更少)的數(shù)據(jù)的高風險。因此，需要對后端進行調(diào)整，以滿足新的數(shù)據(jù)需求，這會降低生產(chǎn)力并顯著降低將用戶反饋集成到產(chǎn)品中的能力。 使用GraphQL這個問題就解決了。由于GraphQL的靈活性，無需在服務(wù)器上額外工作就可以在客戶端上進行更改。由于客戶端可以指定準確的數(shù)據(jù)需求，所以當前端的設(shè)計和數(shù)據(jù)需求發(fā)生變化時，并不需要后端API做出任何的修改就可以滿足展現(xiàn)層的變化。

?4. Schema和類型系統(tǒng)的好處

GraphQL使用強大的Type System來定義API的功能。所有在API中公開的類型都是使用GraphQL schema Definition Language (SDL)在模式中編寫的。該模式充當客戶端和服務(wù)器之間的契約，以定義客戶機如何訪問數(shù)據(jù)。 一旦定義了模式，在前端和后端工作的團隊就可以在沒有進一步通信的情況下完成工作，因為他們都知道通過網(wǎng)絡(luò)發(fā)送的數(shù)據(jù)的確切結(jié)構(gòu)。 前端團隊可以通過mock所需的數(shù)據(jù)結(jié)構(gòu)來輕松測試他們的應(yīng)用程序。一旦后端API實現(xiàn)完成，就可以對客戶端應(yīng)用程序進行切換來調(diào)用實際的API獲取數(shù)據(jù)，這也可以使得我們實現(xiàn)更好的客戶端和服務(wù)端的分離。

?我們可以看出GraphQL的出現(xiàn)可以使得我們后端API具有更大的靈活性以及擴展性以滿足不同client對數(shù)據(jù)的需要，這大大豐富了API的數(shù)據(jù)提供的能力。?

原文地址：https://www.cnblogs.com/xiandnc/p/9162298.html

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的GraphQL 的前世今生的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。