如何解析GraphQL的閱歷

如何解析GraphQL的閱歷，相信很多沒(méi)有經(jīng)驗(yàn)的人對(duì)此束手無(wú)策，為此本文總結(jié)了問(wèn)題出現(xiàn)的原因和解決方法，通過(guò)這篇文章希望你能解決這個(gè)問(wèn)題。

GraphQL是什么

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

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

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

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

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

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

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

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

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

GraphQL和RESTful的區(qū)別

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

 使用REST API來(lái)現(xiàn)實(shí)時(shí)，我們通?？梢酝ㄟ^(guò)訪問(wèn)多次請(qǐng)求來(lái)收集數(shù)據(jù)。比如在這個(gè)示例中，我們可以通過(guò)下面的三步來(lái)實(shí)現(xiàn)：

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

 2. 通過(guò)/user/<id>/posts 返回用戶(hù)的所有帖子

 3. 請(qǐng)求/user/<id>/followers，返回每個(gè)用戶(hù)的關(guān)注者列表

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

如果用GraphQL的話(huà)，我們只需要一次請(qǐng)求就可以完成上述的需求

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

REST最常見(jiàn)的問(wèn)題之一是API的返回?cái)?shù)據(jù)過(guò)多或者過(guò)少，這是因?yàn)榭蛻?hù)端下載數(shù)據(jù)的唯一方法是通過(guò)訪問(wèn)返回固定數(shù)據(jù)結(jié)構(gòu)的endpoint，這就會(huì)導(dǎo)致我們?cè)O(shè)計(jì)API非常困難，因?yàn)樗纫軌驗(yàn)榭蛻?hù)提供精確的數(shù)據(jù)需求，又需要滿(mǎn)足不同調(diào)用者的需求，這本身就是相互矛盾的。GraphQL的發(fā)明者Lee Byron提出了一個(gè)很重要的概念： “用圖形來(lái)思考，而不是endpoint”

通過(guò)上述直觀展示我們可以得出一下幾點(diǎn)：

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

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

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

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

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

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

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

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

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

看完上述內(nèi)容，你們掌握如何解析GraphQL的閱歷的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！