我為什么放棄RESTful，全面擁抱GraphQL

序

REST作為一種現(xiàn)代網(wǎng)絡(luò)應(yīng)用非常流行的軟件架構(gòu)風(fēng)格，自從Roy Fielding博士在2000年他的博士論文中提出來(lái)到現(xiàn)在已經(jīng)有了20年的歷史。它的簡(jiǎn)單易用性，可擴(kuò)展性，伸縮性受到廣大Web開(kāi)發(fā)者的喜愛(ài)。

REST 的 API 配合JSON格式的數(shù)據(jù)交換，使得前后端分離、數(shù)據(jù)交互變得非常容易，而且也已經(jīng)成為了目前Web領(lǐng)域最受歡迎的軟件架構(gòu)設(shè)計(jì)模式。

但隨著REST API的流行和發(fā)展，它的缺點(diǎn)也暴露了出來(lái)：

• 「濫用REST接口」，導(dǎo)致大量相似度很高（具有重復(fù)性）的API越來(lái)越冗余。
• 「對(duì)于前端而言」：REST API粒度較粗，難以一次性符合前端的數(shù)據(jù)要求，前端需要分多次請(qǐng)求接口數(shù)據(jù)。增加了前端人員的工作量。
• 對(duì)于后端而言：「前端需要的數(shù)據(jù)往往在不同的地方具有相似性，但卻又不同」，比如針對(duì)同樣的用戶(hù)信息，有的地方只需要用戶(hù)簡(jiǎn)要信息（比如頭像、昵稱(chēng)），有些地方需要詳細(xì)的信息，這就需要開(kāi)發(fā)不同的接口來(lái)滿(mǎn)足這些需求。當(dāng)這樣的相似但又不同的地方多的時(shí)候，就需要開(kāi)發(fā)更多的接口來(lái)滿(mǎn)足前端的需要。增加了后端開(kāi)發(fā)人員的工作量和重復(fù)度。那我們來(lái)分析一下，當(dāng)前端需求變化，涉及到改動(dòng)舊需求時(shí)，會(huì)有以下這些情況：

0.1、做加法：

產(chǎn)品需求增加，頁(yè)面需要增加功能，數(shù)據(jù)也就相應(yīng)的要增加顯示，那么REST接口也需要做增加，這種無(wú)可厚非。

0.2、做減法：

產(chǎn)品需求減少，頁(yè)面需要減少功能，或者減少某些信息顯示，那么數(shù)據(jù)就要做減法。

「一種通常懶惰的做法是，前端不與后端溝通，僅在前端對(duì)數(shù)據(jù)選擇性顯示?！?/strong>

因?yàn)楹蠖私涌谀軌驖M(mǎn)足數(shù)據(jù)需要，僅僅是在做顯示的時(shí)候?qū)?shù)據(jù)進(jìn)行了選擇性顯示，但接口的數(shù)據(jù)是存在冗余的，這種情況一個(gè)是存在數(shù)據(jù)泄露風(fēng)險(xiǎn)，另外就是數(shù)據(jù)量過(guò)大時(shí)造成網(wǎng)絡(luò)流量過(guò)大，頁(yè)面加載緩慢，用戶(hù)流量費(fèi)白白消耗，用戶(hù)體驗(yàn)就會(huì)下降。

「另外一種做法就是告知后端，要么開(kāi)發(fā)新的接口，要么，修改舊接口，刪掉冗余字段?！?/strong>

但一般來(lái)說(shuō)，開(kāi)發(fā)新接口往往是后端開(kāi)發(fā)人員會(huì)選擇的方案，因?yàn)檫@個(gè)方案對(duì)現(xiàn)有系統(tǒng)的影響最低，不會(huì)有額外的風(fēng)險(xiǎn)。

修改舊接口刪除冗余數(shù)據(jù)的方案往往開(kāi)發(fā)人員不會(huì)選擇，這是為什么呢？

這就涉及到了系統(tǒng)的穩(wěn)定性問(wèn)題了，舊接口往往不止是一個(gè)地方在用，很有可能很多頁(yè)面、設(shè)置不同客戶(hù)端、不同服務(wù)都調(diào)用了這個(gè)接口獲取數(shù)據(jù)，不做詳細(xì)的調(diào)查，是不可能知道到底舊接口被調(diào)用了多少次，一旦改動(dòng)舊接口，涉及范圍可能非常大，往往會(huì)引起其他地方出現(xiàn)崩潰。改動(dòng)舊接口成本太高，所以往往不會(huì)被采取。

0.3、同時(shí)做加減法：

既有加法，又有減法，其實(shí)這種就跟新需求沒(méi)啥區(qū)別，前端需要重做頁(yè)面，后端需要新寫(xiě)接口滿(mǎn)足前端需要，但是舊接口還是不能輕舉妄動(dòng)（除非確定只有這一處調(diào)用才可以刪除）。

往往這個(gè)時(shí)候，其實(shí)用到的數(shù)據(jù)大多都是來(lái)自于同一個(gè)DO或者DTO，不過(guò)是在REST接口組裝數(shù)據(jù)時(shí)，用不同的VO來(lái)封裝不同字段，或者，使用同樣的VO，組裝數(shù)據(jù)時(shí)做刪減。

看到這些問(wèn)題是不是覺(jué)得令人頭大？

所以「需求頻繁改動(dòng)是萬(wàn)惡之源」，當(dāng)產(chǎn)品小哥哥改動(dòng)需求時(shí)，程序員小哥哥可能正提著鐵鍬趕來(lái)......

那么有沒(méi)有一種方案或者框架，可以使得在用到同一個(gè)領(lǐng)域模型（DO或者DTO）的數(shù)據(jù)時(shí)，前端對(duì)于這個(gè)模型的數(shù)據(jù)字段需求的改動(dòng)，后端可以根據(jù)前端的改動(dòng)和需要，自動(dòng)適配，自動(dòng)組裝需要的字段，返回給前端呢？如果能這樣做的話，那么后端程序猿小哥可能要開(kāi)心死了，前端妹子也不用那么苦口婆心地勸說(shuō)后端小哥哥了。

所以 GraphQL 隆重出世了！那么問(wèn)題來(lái)了！

壹、What is GraphQL

1.1、GraphQL 是什么

• GraphQL是一種新的API標(biāo)準(zhǔn)，它提供了一種比REST更有效、更強(qiáng)大和更靈活的替代方案。
• 它是由Facebook開(kāi)發(fā)并開(kāi)源的，現(xiàn)在由來(lái)自世界各地的公司和個(gè)人組成的大型社區(qū)維護(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ù)的接口。
• 它是數(shù)據(jù)庫(kù)無(wú)關(guān)的，而且可以在使用API的任何環(huán)境中有效使用，我們可以理解為GraphQL是基于API之上的一層封裝，目的是為了更好，更靈活的適用于業(yè)務(wù)的需求變化。

「簡(jiǎn)單的來(lái)說(shuō)：」

• 是強(qiáng)大的 API 查詢(xún)語(yǔ)言
• 是客服端和服務(wù)器進(jìn)行通訊的中介
• 比 REST API 更加靈活

它的工作模式是這樣子的：

1.2、GraphQL 對(duì)比 REST API 有什么好處？

R「EST API 的接口靈活性差、接口操作流程繁瑣，GraphQL 的聲明式數(shù)據(jù)獲取，使得接口數(shù)據(jù)精確返回，數(shù)據(jù)查詢(xún)流程簡(jiǎn)潔，照顧了客戶(hù)端的靈活性。」

「客戶(hù)端拓展功能時(shí)要不斷編寫(xiě)新接口（依賴(lài)于服務(wù)端），GraphQL 中一個(gè)服務(wù)僅暴露一個(gè) GraphQL 層，消除了服務(wù)器對(duì)數(shù)據(jù)格式的硬性規(guī)定，客戶(hù)端按需請(qǐng)求數(shù)據(jù)，可進(jìn)行單獨(dú)維護(hù)和改進(jìn)。」

「REST API 基于HTTP協(xié)議，不能靈活選擇網(wǎng)絡(luò)協(xié)議，而傳輸層無(wú)關(guān)、數(shù)據(jù)庫(kù)技術(shù)無(wú)關(guān)使得 GraphQL 有更加靈活的技術(shù)棧選擇，能夠?qū)崿F(xiàn)在網(wǎng)絡(luò)協(xié)議層面優(yōu)化應(yīng)用?！?/strong>

舉個(gè)經(jīng)典例子

前端向后端請(qǐng)求一個(gè)book對(duì)象的數(shù)據(jù)及其作者信息。

我用動(dòng)圖來(lái)分別演示下REST和GraphQL是怎么樣的一個(gè)過(guò)程。

先看REST API的做法：

再來(lái)看GraphQL是怎么做的：

可以看出其中的區(qū)別：

與REST多個(gè)endpoint不同，每一個(gè)的 GraphQL 服務(wù)其實(shí)對(duì)外只提供了一個(gè)用于調(diào)用內(nèi)部接口的端點(diǎn)，所有的請(qǐng)求都訪問(wèn)這個(gè)暴露出來(lái)的唯一端點(diǎn)。

GraphQL 實(shí)際上將多個(gè) HTTP 請(qǐng)求聚合成了一個(gè)請(qǐng)求，將多個(gè) restful 請(qǐng)求的資源變成了一個(gè)從根資源 POST 訪問(wèn)其他資源的 Comment 和 Author 的圖，多個(gè)請(qǐng)求變成了一個(gè)請(qǐng)求的不同字段，從原有的分散式請(qǐng)求變成了集中式的請(qǐng)求，因此GraphQL又可以被看成是圖數(shù)據(jù)庫(kù)的形式。

那我們已經(jīng)能看到GraphQL的先進(jìn)性，接下來(lái)看看它是怎么做的。

1.3、GraphQL 思考模式

使用GraphQL接口設(shè)計(jì)獲取數(shù)據(jù)需要三步：

• 1、首先要設(shè)計(jì)數(shù)據(jù)模型，用來(lái)描述數(shù)據(jù)對(duì)象，它的作用可以看做是VO，用于告知GraphQL如何來(lái)描述定義的數(shù)據(jù)，為下一步查詢(xún)返回做準(zhǔn)備；
• 2、前端使用模式查詢(xún)語(yǔ)言（Schema）來(lái)描述需要請(qǐng)求的數(shù)據(jù)對(duì)象類(lèi)型和具體需要的字段（稱(chēng)之為聲明式數(shù)據(jù)獲取）；
• 3、后端GraphQL通過(guò)前端傳過(guò)來(lái)的請(qǐng)求，根據(jù)需要，自動(dòng)組裝數(shù)據(jù)字段，返回給前端。GraphQL的這種思考模式是不是完美解決了之前遇到的問(wèn)題呢？！

「總結(jié)它的好處」：

在它的設(shè)計(jì)思想中，GraphQL 以圖的形式將整個(gè) Web 服務(wù)中的資源展示出來(lái)，客戶(hù)端可以按照其需求自行調(diào)用，類(lèi)似添加字段的需求其實(shí)就不再需要后端多次修改了。

創(chuàng)建GraphQL服務(wù)器的最終目標(biāo)是：允許查詢(xún)通過(guò)圖和節(jié)點(diǎn)的形式去獲取數(shù)據(jù)。

1.4、GraphQL執(zhí)行邏輯

有人會(huì)問(wèn)：

• 使用了GraphQL就要完全拋棄REST了嗎？
• GraphQL需要直接對(duì)接數(shù)據(jù)庫(kù)嗎？
• 使用GraphQL需要對(duì)現(xiàn)有的后端服務(wù)進(jìn)行大刀闊斧的修改嗎？

答案是：NO！不需要！

它完全可以以一種不侵入的方式來(lái)部署，將它作為前后端的中間服務(wù)，也就是，現(xiàn)在開(kāi)始逐漸流行的 「前端 —— 中端 —— 后端」 的三層結(jié)構(gòu)模式來(lái)部署！

那就來(lái)看一下這樣的部署模式圖：

也就是說(shuō)，完全可以搭建一個(gè)GraphQL服務(wù)器，專(zhuān)門(mén)來(lái)處理前端請(qǐng)求，并處理后端服務(wù)獲取的數(shù)據(jù)，重新進(jìn)行組裝、篩選、過(guò)濾，將完美符合前端需要的數(shù)據(jù)返回。歡迎關(guān)注公眾號(hào)"Java學(xué)習(xí)之道"，查看更多干貨！

新的開(kāi)發(fā)需求可以直接就使用GraphQL服務(wù)來(lái)獲取數(shù)據(jù)了，以前已經(jīng)上線的功能無(wú)需改動(dòng)，還是使用原有請(qǐng)求調(diào)用REST接口的方式，最低程度的降低更換GraphQL帶來(lái)的技術(shù)成本問(wèn)題！

如果沒(méi)有那么多成本來(lái)支撐改造，那么就不需要改造！

只有當(dāng)原有需求發(fā)生變化，需要對(duì)原功能進(jìn)行修改時(shí)，就可以換成GraphQL了。

1.5、GraphQL應(yīng)用的基本架構(gòu)

下圖是一個(gè) GraphQL 應(yīng)用的基本架構(gòu)，其中客戶(hù)端只和 GraphQL 層進(jìn)行 API 交互，而 GraphQL 層再往后接入各種數(shù)據(jù)源。這樣一來(lái)，只要是數(shù)據(jù)源有的數(shù)據(jù)， GraphQL 層都可以讓客戶(hù)端按需獲取，不必專(zhuān)門(mén)再去定接口了。

「一個(gè)GraphQL服務(wù)僅暴露一個(gè) GraphQL Endpoint，可以按照業(yè)務(wù)來(lái)進(jìn)行區(qū)分，部署多個(gè)GraphQL服務(wù)，分管不同的業(yè)務(wù)數(shù)據(jù)，這樣就可以避免單服務(wù)器壓力過(guò)大的問(wèn)題了?！?/strong>

1.6、GraphQL特點(diǎn)總結(jié)

• 「聲明式數(shù)據(jù)獲取（可以對(duì)API進(jìn)行查詢(xún)）:」 聲明式的數(shù)據(jù)查詢(xún)帶來(lái)了接口的精確返回，服務(wù)器會(huì)按數(shù)據(jù)查詢(xún)的格式返回同樣結(jié)構(gòu)的 JSON 數(shù)據(jù)、真正照顧了客戶(hù)端的靈活性。
• 「一個(gè)微服務(wù)僅暴露一個(gè) GraphQL 層」：一個(gè)微服務(wù)只需暴露一個(gè)GraphQL endpoint，客戶(hù)端請(qǐng)求相應(yīng)數(shù)據(jù)只通過(guò)該端點(diǎn)按需獲取，不需要再額外定義其他接口。
• 「?jìng)鬏攲訜o(wú)關(guān)、數(shù)據(jù)庫(kù)技術(shù)無(wú)關(guān)」：帶來(lái)了更靈活的技術(shù)棧選擇，比如我們可以選擇對(duì)移動(dòng)設(shè)備友好的協(xié)議，將網(wǎng)絡(luò)傳輸數(shù)據(jù)量最小化，實(shí)現(xiàn)在網(wǎng)絡(luò)協(xié)議層面優(yōu)化應(yīng)用。

貳、Schema & Type

GraphQL支持的數(shù)據(jù)操作 GraphQL對(duì)數(shù)據(jù)支持的操作有：

• 「查詢(xún)（Query）」：獲取數(shù)據(jù)的基本查詢(xún)。
• 「變更（Mutation）」：支持對(duì)數(shù)據(jù)的增刪改等操作。
• 「訂閱（Subscription）」：用于監(jiān)聽(tīng)數(shù)據(jù)變動(dòng)、并靠websocket等協(xié)議推送變動(dòng)的消息給對(duì)方。

2.1、GraphQL的核心概念：圖表模式（Schema）

要想要設(shè)計(jì)GraphQL的數(shù)據(jù)模型，用來(lái)描述你的業(yè)務(wù)數(shù)據(jù)，那么就必須要有一套Schema語(yǔ)法來(lái)做支撐。

想要描述數(shù)據(jù)，就必須離不開(kāi)數(shù)據(jù)類(lèi)型的定義。所以GraphQL設(shè)計(jì)了一套Schema模式（可以理解為語(yǔ)法），其中最重要的就是數(shù)據(jù)類(lèi)型的定義和支持。

那么類(lèi)型（Type）就是模式（Schema）最核心的東西了。

「什么是類(lèi)型？」

• 對(duì)于數(shù)據(jù)模型的抽象是通過(guò)類(lèi)型（Type）來(lái)描述的，每一個(gè)類(lèi)型有若干字段（Field）組成，每個(gè)字段又分別指向某個(gè)類(lèi)型（Type）。這很像Java、C#中的類(lèi)（Class）。
• GraphQL的Type簡(jiǎn)單可以分為兩種，一種叫做Scalar Type(標(biāo)量類(lèi)型)，另一種叫做Object Type(對(duì)象類(lèi)型)。

那么就分別來(lái)介紹下兩種類(lèi)型。

2.2、標(biāo)量類(lèi)型（Scalar Type）

標(biāo)量是GraphQL類(lèi)型系統(tǒng)中最小的顆粒。類(lèi)似于Java、C#中的基本類(lèi)型。

其中內(nèi)建標(biāo)量主要有：

• String
• Int
• Float
• Boolean
• Enum
• ID

上面的類(lèi)型僅僅是GraphQL默認(rèn)內(nèi)置的類(lèi)型，當(dāng)然，為了保證最大的靈活性，GraphQL還可以很靈活的自行創(chuàng)建標(biāo)量類(lèi)型。

2.3、對(duì)象類(lèi)型（Object Type）

僅有標(biāo)量類(lèi)型是不能滿(mǎn)足復(fù)雜抽象數(shù)據(jù)模型的需要，這時(shí)候我們可以使用對(duì)象類(lèi)型。

通過(guò)對(duì)象模型來(lái)構(gòu)建GraphQL中關(guān)于一個(gè)數(shù)據(jù)模型的形狀，同時(shí)還可以聲明各個(gè)模型之間的內(nèi)在關(guān)聯(lián)（一對(duì)多、一對(duì)一或多對(duì)多）。

對(duì)象類(lèi)型的定義可以參考下圖：

是不是很方便呢？我們可以像設(shè)計(jì)類(lèi)圖一樣來(lái)設(shè)計(jì)GraphQL的對(duì)象模型。

2.4、類(lèi)型修飾符（Type Modifier）

那么，類(lèi)型系統(tǒng)僅僅只有類(lèi)型定義是不夠的，我們還需要對(duì)類(lèi)型進(jìn)行更廣泛性的描述。

類(lèi)型修飾符就是用來(lái)修飾類(lèi)型，以達(dá)到額外的數(shù)據(jù)類(lèi)型要求控制。

比如：

• 列表：[Type]
• 非空：Type!
• 列表非空：[Type]!
• 非空列表，列表內(nèi)容類(lèi)型非空：[Type!]!

在描述數(shù)據(jù)模型（模式Schema）時(shí)，就可以對(duì)字段施加限制條件。

例如定義了一個(gè)名為User的對(duì)象類(lèi)型，并對(duì)其字段進(jìn)行定義和施加限制條件：

那么，返回?cái)?shù)據(jù)時(shí)，像下面這種情況就是不允許的：

Graphql會(huì)根據(jù)Schema Type來(lái)自動(dòng)返回正確的數(shù)據(jù)：

2.5、其他類(lèi)型

除了上面的，Graphql還有一些其他類(lèi)型來(lái)更好的引入面向?qū)ο蟮脑O(shè)計(jì)思想：

接口類(lèi)型（Interfaces）

其他對(duì)象類(lèi)型實(shí)現(xiàn)接口必須包含接口所有的字段，并具有相同的類(lèi)型修飾符，才算實(shí)現(xiàn)接口。

比如定義了一個(gè)接口類(lèi)型：

那么就可以實(shí)現(xiàn)該接口：

聯(lián)合類(lèi)型（Union Types）

聯(lián)合類(lèi)型和接口十分相似，但是它并不指定類(lèi)型之間的任何共同字段。幾個(gè)對(duì)象類(lèi)型共用一個(gè)聯(lián)合類(lèi)型。

輸入類(lèi)型（Input Types）

更新數(shù)據(jù)時(shí)有用，與常規(guī)對(duì)象只有關(guān)鍵字修飾不一樣，常規(guī)對(duì)象時(shí) type 修飾，輸入類(lèi)型是 input 修飾。比如定義了一個(gè)輸入類(lèi)型：

前端發(fā)送變更請(qǐng)求時(shí)就可以使用（通過(guò)參數(shù)來(lái)指定輸入的類(lèi)型）：

所以，這樣面向?qū)ο蟮脑O(shè)計(jì)方式，真的對(duì)后端開(kāi)發(fā)人員特別友好！而且前端MVVM框架流行以來(lái)，面向?qū)ο蟮脑O(shè)計(jì)思想也越來(lái)越流行，前端使用Graphql也會(huì)得心應(yīng)手。

叁、GraphQL 技術(shù)接入架構(gòu)

那么，該怎么設(shè)計(jì)來(lái)接入我們現(xiàn)有的系統(tǒng)中呢？

1、「將Graphql服務(wù)直連數(shù)據(jù)庫(kù)的方式」：最簡(jiǎn)潔的配置，直接操作數(shù)據(jù)庫(kù)能減少中間環(huán)節(jié)的性能消耗。

2、「集成現(xiàn)有服務(wù)的 GraphQL 層」：這種配置適合于舊服務(wù)的改造，尤其是在涉及第三方服務(wù)時(shí)、依然可以通過(guò)原有接口進(jìn)行交互。

![集成現(xiàn)有服務(wù)的GraphQL層

](http://p6-tt.byteimg.com/large/pgc-image/87212a85e6aa4773b325c004ad4a0ac0?from=pc)

3、「直連數(shù)據(jù)庫(kù)和集成服務(wù)的混合模式」：前兩種方式的混合。

可以說(shuō)是非常靈活了！你都不用擔(dān)心會(huì)給你帶來(lái)任何的麻煩。

肆、GraphQL 開(kāi)源生態(tài)圈

4.1、服務(wù)端實(shí)現(xiàn)

在服務(wù)端， GraphQL 服務(wù)器可用任何可構(gòu)建 Web 服務(wù)器的語(yǔ)言實(shí)現(xiàn)。

有以下語(yǔ)言的實(shí)現(xiàn)供參考：

• C# / .NET
• Clojure
• Elixir
• Erlang
• Go
• Groovy
• Java
• JavaScript
• Julia
• Kotlin
• Perl
• PHP
• Python
• R
• Ruby
• Rust
• Scala
• Swift

種類(lèi)繁多，幾乎流行的語(yǔ)言都有支持。

4.2、客戶(hù)端實(shí)現(xiàn)

在客戶(hù)端，Graphql Client目前有下面的語(yǔ)言支持：

• C# / .NET
• Clojurescript
• Elm
• Flutter
• Go
• Java / Android
• JavaScript
• Julia
• Swift / Objective-C iOS
• Python
• R 覆蓋了眾多客戶(hù)端設(shè)計(jì)語(yǔ)言，而其他語(yǔ)言的支持也在推進(jìn)中。

4.3、Graphql的一些服務(wù)

整理了下目前比較流行的服務(wù)框架：

• 「Apollo Engine」:一個(gè)用于監(jiān)視 GraphQL 后端的性能和使用的服務(wù)。
• 「Graphcool (github)」: 一個(gè) BaaS（后端即服務(wù)），它為你的應(yīng)用程序提供了一個(gè) GraphQL 后端，且具有用于管理數(shù)據(jù)庫(kù)和存儲(chǔ)數(shù)據(jù)的強(qiáng)大的 web ui。
• 「Tipe (github)」: 一個(gè) SaaS（軟件即服務(wù)）內(nèi)容管理系統(tǒng)，允許你使用強(qiáng)大的編輯工具創(chuàng)建你 的內(nèi)容，并通過(guò) GraphQL 或 REST API 從任何地方訪問(wèn)它。
• 「AWS AppSync」：完全托管的 GraphQL 服務(wù)，包含實(shí)時(shí)訂閱、離線編程和同步、企業(yè)級(jí)安全特性以及細(xì)粒度的授權(quán)控制。
• 「Hasura」：一個(gè) BaaS（后端即服務(wù)），允許你在 Postgres 上創(chuàng)建數(shù)據(jù)表、定義權(quán)限并使用 GraphQL 接口查詢(xún)和操作。

Graphql的一些工具

• 「graphiql (npm)」: 一個(gè)交互式的運(yùn)行于瀏覽器中的 GraphQL IDE。
• 「Graphql Language Service」: 一個(gè)用于構(gòu)建 IDE 的 GraphQL 語(yǔ)言服務(wù)（診斷、自動(dòng)完成等） 的接口。
• 「quicktype (github)」: 在 TypeScript、Swift、golang、C#、C++ 等語(yǔ)言中為 GraphQL 查 詢(xún)生成類(lèi)型。想要獲取更多關(guān)于Graphql的一些框架、工具，可以去awesome-graphql：一個(gè)神奇的社區(qū)，維護(hù)一系列庫(kù)、資源等，地址是：https://github.com/chentsulin/awesome-graphql

想要學(xué)習(xí)更多Graphql的知識(shí)，可以去GraphQL.cn

好了，一個(gè)入門(mén)級(jí)的Graphql介紹篇就這樣完結(jié)了（盡管篇幅也很大哈哈）。

獲得原創(chuàng)整理：《第2版：互聯(lián)網(wǎng)大廠面試題》