TLDR：使用 GraphQL 進(jìn)行客戶端-服務(wù)器通信，使用 gRPC 進(jìn)行服務(wù)器到服務(wù)器通信。有關(guān)此規(guī)則的例外情況，請參閱“判定”部分。

我已經(jīng)閱讀了很多關(guān)于這兩種協(xié)議的比較，并想寫一個(gè)全面和公正的協(xié)議。（好吧，就像我和我的審稿人所能做到的那樣公正

。我的靈感來自connect-web（一個(gè)可以在瀏覽器中使用的TypeScript gRPC客戶端）的發(fā)布，以及一篇名為GraphQL的流行HN帖子有點(diǎn)糟糕。我個(gè)人在第7 層之上構(gòu)建的通信協(xié)議歷史：

REST（Rails and Express）

DDP（Meteor's WebSocket Protocol)

GraphQL（我寫了一本書）

gRPC（我在Temporal 使用）)

背景

gRPC由 Google 于 2016 年發(fā)布，是一種高效且開發(fā)人員友好的服務(wù)器到服務(wù)器通信方法。GraphQL由 Meta 于 2015 年發(fā)布，作為一種高效且開發(fā)人員友好的客戶端-服務(wù)器通信方法。它們都比 REST 具有顯著的優(yōu)勢，并且有很多共同點(diǎn)。我們將用大部分時(shí)間比較它們的特征，然后總結(jié)每個(gè)協(xié)議的優(yōu)點(diǎn)和缺點(diǎn)。最后，我們將知道為什么每個(gè)都非常適合其預(yù)期域，以及何時(shí)可能希望在另一個(gè)域中使用一個(gè)。

比較 gRPC 和 GraphQL 特性

界面設(shè)計(jì)

gRPC 和 GraphQL 都是接口描述語言 （IDL），用于描述兩臺計(jì)算機(jī)如何相互通信。它們跨不同的編程語言工作，我們可以使用 codegen 工具來生成多種語言的類型化接口。IDL 抽象出傳輸層;GraphQL 與傳輸無關(guān)，但通常通過 HTTP 使用，而 gRPC 使用 HTTP/2。我們不需要了解傳輸級的詳細(xì)信息，例如 REST 中的方法、路徑、查詢參數(shù)和正文格式。我們只需要知道使用更高級別的客戶端庫與之通信的單個(gè)端點(diǎn)。

消息格式

郵件大小很重要，因?yàn)檩^小的郵件通常通過網(wǎng)絡(luò)發(fā)送所需的時(shí)間較短。gRPC 使用協(xié)議緩沖區(qū)（又名 protobufs），這是一種只包含值的二進(jìn)制格式，而 GraphQL 使用 JSON，它是基于文本的，除了值之外還包括字段名稱。二進(jìn)制格式與較少的信息相結(jié)合通常會(huì)導(dǎo)致 gRPC 消息小于 GraphQL 消息。（雖然高效的二進(jìn)制格式在 GraphQL 中是可行的，但它很少使用，并且不受大多數(shù)庫和工具的支持。

影響消息大小的另一個(gè)方面是過度獲取：我們是可以只請求特定字段還是始終接收所有字段（我們不需要的“過度提取”字段）。GraphQL 總是在請求中指定需要哪些字段，而在 gRPC 中，我們可以將FieldMask用作請求的可重用過濾器。

gRPC 二進(jìn)制格式的另一個(gè)好處是，與 GraphQL 的文本消息相比，消息的序列化和解析速度更快。缺點(diǎn)是它比人類可讀的 JSON 更難查看和調(diào)試。我們默認(rèn)使用 protobuf 的JSON 格式，以獲得開發(fā)人員體驗(yàn)的可見性優(yōu)勢。（這失去了二進(jìn)制格式帶來的效率，但更重視效率的用戶可以切換到二進(jìn)制。

違約

gRPC 也不在消息中包含默認(rèn)值，GraphQL 可以對參數(shù)執(zhí)行此操作，但不能對請求字段或響應(yīng)類型執(zhí)行此操作。這是 gRPC 消息較小的另一個(gè)因素。它還會(huì)影響使用 gRPC API 的 DX。將輸入字段保留為未設(shè)置和將其設(shè)置為默認(rèn)值之間沒有區(qū)別，默認(rèn)值基于字段的類型。所有布爾值默認(rèn)為 false，所有數(shù)字和枚舉默認(rèn)為 0。我們不能將“behavior”枚舉輸入字段默認(rèn)為“BEHAVIOR_FOO = 2”——我們必須將默認(rèn)值放在第一位（“BEHAVIOR_FOO = 0”），這意味著它將來將始終是默認(rèn)值，或者我們遵循推薦的做法，即使用“BEHAVIOR_UNSPECIFIED = 0”枚舉值：

enum Behavior {
  BEHAVIOR_UNSPECIFIED = 0;
  BEHAVIOR_FOO = 1;
  BEHAVIOR_BAR = 2;
}

API 提供者需要傳達(dá) whatmeans（通過記錄“未指定將使用默認(rèn)行為，這是當(dāng)前”），消費(fèi)者需要考慮服務(wù)器默認(rèn)行為將來是否會(huì)發(fā)生變化（如果服務(wù)器將 offer/ 0 值保存在消費(fèi)者正在創(chuàng)建的某個(gè)業(yè)務(wù)實(shí)體中，并且服務(wù)器稍后更改了默認(rèn)行為， 實(shí)體將開始以不同的方式行事）以及是否需要這樣做。如果不需要，客戶端需要將值設(shè)置為當(dāng)前默認(rèn)值。下面是一個(gè)示例方案：UNSPECIFIEDFOOUNSPECIFIED

service ExampleGrpcService {
  rpc CreateEntity (CreateEntityRequest) returns (CreateEntityResponse) {}
}

message CreateEntityRequest {
  string name = 1;
  Behavior behavior = 2;
}

如果我們這樣做：

const request = new CreateEntityRequest({ name: “my entity” })
service.CreateEntity(request)

我們將發(fā)送，根據(jù)服務(wù)器實(shí)現(xiàn)和未來的更改，這可能意味著現(xiàn)在和以后。或者我們可以做：BEHAVIOR_UNSPECIFIEDBEHAVIOR_FOOBEHAVIOR_BAR

const request = new CreateEntityRequest({ name: “my entity”, behavior: Behavior.BEHAVIOR_FOO })
service.CreateEntity(request)

可以肯定的是，該行為被存儲為“將保留”。FOOFOO

等效的 GraphQL 模式將是：

type Mutation {
  createEntity(name: String, behavior: Behavior = FOO): Entity
}

enum Behavior {
  FOO
  BAR
}

當(dāng)我們不在請求中包含時(shí)，服務(wù)器代碼將接收并將 FOO 存儲為值，與上述架構(gòu)中的默認(rèn)值匹配。behavior= FOO

graphqlClient.request(`
  mutation  {
    createEntity(name: “my entity”)
  }
`

知道如果未提供字段會(huì)發(fā)生什么情況，它比 gRPC 版本更簡單，我們不需要考慮是否自己傳遞默認(rèn)值。

其他類型的默認(rèn)值還有其他怪癖。對于數(shù)字，有時(shí)默認(rèn)值 0 是有效值，有時(shí)表示不同的默認(rèn)值。對于布爾值，默認(rèn)的 false 會(huì)導(dǎo)致負(fù)命名字段。當(dāng)我們在編碼時(shí)命名布爾變量時(shí)，我們使用正名稱。例如，我們通常會(huì)聲明而不是。人們通常發(fā)現(xiàn)前者更具可讀性，因?yàn)楹笳咝枰~外的步驟來理解雙重否定（“是，所以它是可重試的”）。但是，如果我們有一個(gè) gRPC API，我們希望默認(rèn)狀態(tài)是可重試的，那么我們必須命名該字段，因?yàn)?anfield 的默認(rèn)值將是，就像 gRPC 中的所有布爾值一樣。let retryable = truelet nonRetryable = falsenotRetryablefalsenonRetryableretryablefalse

請求格式

在 gRPC 中，我們一次調(diào)用一個(gè)方法。如果我們需要的數(shù)據(jù)多于單個(gè)方法提供的數(shù)據(jù)，則需要調(diào)用多個(gè)方法。如果我們需要來自第一個(gè)方法的響應(yīng)數(shù)據(jù)，以便知道下一步要調(diào)用哪個(gè)方法，那么我們將連續(xù)進(jìn)行多次往返。除非我們與服務(wù)器位于同一數(shù)據(jù)中心，否則會(huì)導(dǎo)致明顯的延遲。此問題稱為獲取不足。

這是 GraphQL 旨在解決的問題之一。在高延遲移動(dòng)電話連接中，能夠在單個(gè)請求中獲取所需的所有數(shù)據(jù)尤為重要。在 GraphQL 中，我們發(fā)送一個(gè)字符串（稱為文檔）以及我們的請求，其中包含我們要調(diào)用的所有方法（稱為查詢和突變）以及基于第一級結(jié)果所需的所有嵌套數(shù)據(jù)。某些嵌套數(shù)據(jù)可能需要從服務(wù)器到數(shù)據(jù)庫的后續(xù)請求，但它們通常位于同一數(shù)據(jù)中心，該數(shù)據(jù)中心應(yīng)具有亞毫秒級的網(wǎng)絡(luò)延遲。

GraphQL 的請求靈活性讓前端和后端團(tuán)隊(duì)變得不那么耦合。前端開發(fā)人員可以向其請求添加更多查詢或嵌套結(jié)果字段，而不是前端開發(fā)人員等待后端開發(fā)人員向方法的響應(yīng)添加更多數(shù)據(jù)（以便客戶端可以在單個(gè)請求中接收數(shù)據(jù)）。當(dāng)有一個(gè)覆蓋組織整個(gè)數(shù)據(jù)圖的 GraphQL API 時(shí)，前端團(tuán)隊(duì)在等待后端更改時(shí)被阻止的頻率要低得多。

事實(shí)上，GraphQL 請求指定了所有需要的數(shù)據(jù)字段，這意味著客戶端可以使用聲明性數(shù)據(jù)獲取：而不是命令性獲取數(shù)據(jù)（如調(diào)用 'grpcClient.callMethod（）“），我們在視圖組件旁邊聲明我們需要的數(shù)據(jù)，GraphQL 客戶端庫將這些部分組合成一個(gè)請求，并在響應(yīng)到達(dá)時(shí)和稍后數(shù)據(jù)更改時(shí)將數(shù)據(jù)提供給組件。Web 開發(fā)中視圖庫的并行是使用 React 而不是 jQuery：聲明我們的組件應(yīng)該是什么樣子，并在數(shù)據(jù)更改時(shí)自動(dòng)更新它們，而不是使用 jQuery 強(qiáng)制操作 DOM。

GraphQL 的請求格式的另一個(gè)影響是提高了可見性：服務(wù)器可以看到請求的每個(gè)字段。我們可以跟蹤字段使用情況并查看客戶端何時(shí)停止使用已棄用的字段，以便我們知道何時(shí)可以刪除它們，而不是永遠(yuǎn)支持我們說要?jiǎng)h除的內(nèi)容。跟蹤內(nèi)置于Apollo GraphOS和Stellate等常用工具中。

向前兼容性

gRPC 和 GraphQL 都有很好的前向兼容性;也就是說，很容易在不破壞現(xiàn)有客戶端的情況下更新服務(wù)器。這對于可能已過時(shí)的移動(dòng)應(yīng)用程序尤其重要，但對于在服務(wù)器更新后繼續(xù)工作，用戶瀏覽器選項(xiàng)卡中加載的SPA也是必需的。

在 gRPC 中，可以通過對字段進(jìn)行數(shù)字排序、添加具有新編號的字段以及不更改現(xiàn)有字段的類型/編號來保持向前兼容性。在 GraphQL 中，您可以添加字段，使用 '@deprecated“' 指令棄用舊字段（并讓它們正常工作），并避免更改必需的可選參數(shù)。

運(yùn)輸

gRPC 和 GraphQL 都支持服務(wù)器將數(shù)據(jù)流式傳輸?shù)?/strong>客戶端：gRPC 具有服務(wù)器流式處理，GraphQL 具有訂閱和指令 @defer，@stream 和 @live。gRPC 的 HTTP/2 還支持客戶端和雙向流式處理（盡管當(dāng)一側(cè)是瀏覽器時(shí)，我們不能進(jìn)行雙向流式處理）。HTTP/2 還通過多路復(fù)用提高了性能。