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

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

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

REST（Rails and Express）

DDP（Meteor's WebSocket Protocol)

GraphQL（我寫了一本書）

gRPC（我在Temporal 使用）)

背景

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

比較 gRPC 和 GraphQL 特性

界面設計

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

消息格式

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

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

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

違約

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

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

API 提供者需要傳達 whatmeans（通過記錄“未指定將使用默認行為，這是當前”），消費者需要考慮服務器默認行為將來是否會發(fā)生變化（如果服務器將 offer/ 0 值保存在消費者正在創(chuàng)建的某個業(yè)務實體中，并且服務器稍后更改了默認行為， 實體將開始以不同的方式行事）以及是否需要這樣做。如果不需要，客戶端需要將值設置為當前默認值。下面是一個示例方案：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ù)服務器實現(xiàn)和未來的更改，這可能意味著現(xiàn)在和以后?；蛘呶覀兛梢宰觯築EHAVIOR_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
}

當我們不在請求中包含時，服務器代碼將接收并將 FOO 存儲為值，與上述架構中的默認值匹配。behavior= FOO

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

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

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

請求格式

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

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

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

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

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

向前兼容性

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

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

運輸

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