GraphQL：PayPal結賬的成功案例

在PayPal，GraphQL對我們思考資料，獲取資料和構建應用程式的方式進行了徹底的改變。

這篇博文簡要介紹了PayPal Checkout，並解釋了我們從REST到Batch REST到GraphQL的歷程，以及沿途的經驗教訓。

PayPal的Checkout產品分佈在許多網路和移動應用程式中，支援約200個國家/地區的數百萬使用者，並且可以隨時執行數百個實驗。這些應用程式利用相同的REST API套件來獲取構建UI所需的資料。

大約4年前，我們就都在REST。我們的API很乾淨，小而且原子。一開始事情很棒。REST具有廣泛理解的嚴格設計原則。REST是為領域設計和實現API的好方法。

但是，REST的原則並未考慮Web和移動應用及其使用者的需求。在像Checkout這樣的最佳化交易中尤其如此。使用者希望儘快完成結賬。如果您的應用程式正在使用原子REST API，那麼您經常會從客戶端到伺服器進行多次往返以獲取資料。透過Checkout，我們發現每次往返的網路時間（第99百分位數）至少需要700毫秒，不包括在伺服器上處理請求的時間。每次往返都會導致渲染時間變慢，使用者受挫更多，Checkout轉換率也會降低。不用說，往返是邪惡的！

當然，您可以構建一個業務流程API來返回您需要的所有資料，但這需要權衡利弊。你叫什麼名字？GET /login？現在這看起來像一個JSON API，而不是REST API。使用編排API，您的客戶端將耦合到您的伺服器。每次新增新功能或實驗時，都會將其新增到API中。這有問題。

當新的需求出現時，開發人員面臨一個選擇：我們應該建立一個新的端點並讓我們的客戶再次請求該資料嗎？或者我們應該用更多資料過載現有端點？

開發人員通常會選擇第二個選項，因為它更容易新增另一個欄位並阻止客戶端到伺服器的往返。隨著時間的推移，這會導致您的API變得沉重，笨拙，並且不僅僅會承擔一項責任。

開始時，我們的API返回了使用者資訊，送貨地址和資金選項。構建Checkout應用程式所需的一切。隨著時間的推移，用例堆積起來。即使他們不需要，每個使用者也要支付這些欄位的費用。

編排API(將很多欄位功能塞入API稱為編排)起初看起來很棒，但我們總是後悔。

Batch REST
REST不適用於我們，所以我們構建了一個Batch REST API來解決其中的一些問題。它是一個動態編排API，允許客戶端確定響應的大小和形狀。Batch允許我們組合原子REST請求並減少往返。

以下是批處理請求和響應的示例。該請求包含REST操作的對映，您可以在其中指定動詞，端點，引數和它們之間的依賴關係。

{
"user": {
"method": "get",
"urt": "/apt/user"
},
"createCheckout": {
"method": "post",
"urt": "/api/checkout/EC-1234",
"params": {"total": "10.00", "currencyCode": "USD"}
},
"getCheckout": {
"method": "get",
"urt": "/apt/checkout/EC-1234",
"dependencies": ["createCheckout"]
}

GraphQL去年，我們的經理（Brian Crescimanno）向我們提出了兩個問題：

我們有一些很大的開發人員經驗和效能問題。GraphQL解決了這個問題以及更多問題。

效能  -  您只能獲得所要求的資料。不多也不少。單程往返。您也可以查詢突變的一部分！

靈活性 - 客戶確定資料的大小和形狀，而不是伺服器。

開發人員的生產力 - 立即富有成效，沒有部落知識。如果你瞭解JSON，你就知道GraphQL。令人難以置信的工具！

演進 - 使用GraphQL，API開發人員確切地知道客戶正在使用哪些欄位，並且在棄用或開發其API時能夠做出更好的選擇。使用REST，這是不可能的，因此您可以擴充套件並永不刪除。
 

只是開始
Mobile SDK只是一個開始。我們現在在GraphQL和React之上重新推出我們的旗艦PayPal Checkout產品。如果你在美國，那麼你很有可能使用我們的新產品。它要快得多。

PayPal也正在風暴使用GraphQL。一年後，我們有超過30個應用程式/團隊構建API或使用API​​。這不是所有的陽光和彩虹。我們在一路上犯了一些值得分享的錯誤。