GraphQL：PayPal結賬的成功案例

在PayPal，我們最近將ofollow,noindex" target="_blank">GraphQL 引入了我們的技術堆疊。如果您還沒有聽說過GraphQL ，它是REST API的一種廣受歡迎的替代方案，目前正在風靡開發人員世界！

在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"]
}

使用Batch，我們喜歡客戶端控制資料的大小和形狀，而不是伺服器。這使我們無需在每次客戶端的要求發生變化時調整編排API。我們不喜歡客戶必須非常瞭解底層API的工作原理。請求結構痛苦得足以讓開發人員不使用它。我們還希望能夠獲取特定欄位，而不是大型資源或物件。許多擁有批量產品的公司（如Facebook和Google）都存在同樣的問題。它被視為一種優化但不是獲取資料的正規的首要方法。

批處理REST是朝著正確方向邁出的一步，但不是遊戲規則改變者。

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

摘錄

“2018年構建應用程式的最佳方法是什麼？”

我們知道效能是一個問題。我們覺得我們沒有像我們想要的那樣富有成效。我們知道我們沒有花足夠的時間來構建出色的UI體驗。

當我們仔細觀察時，我們發現UI開發人員花費的時間不到實際構建UI的1/3。剩下的時間用於確定在何處以及如何獲取資料，過濾/對映資料以及編排許多API呼叫。撒上一些構建/部署開銷。

那時，我們開始越來越多地瞭解GraphQL。我們花了一週的時間仔細研究GraphQL並給我們留下了深刻的印象。幸運的是，我們推出了一款新產品，為想要將PayPal Checkout整合到他們的應用程式中的開發人員提供Mobile SDK。我們有6個星期發貨，3個開發商用它來構建它。

“讓我們使用GraphQL！” - 有人

隨著團隊構建UI，我們正在並行構建API。儘管API尚未準備好供他們使用，但我們仍然 提前完成功能/程式碼，幾乎不需要PayPal專業知識。開發人員不必發現要呼叫的內部API，如何呼叫它並將資料轉換為可以使用的內容。他們檢查了我們的模式以找出可能的內容，為他們需要的東西寫了一個GraphQL查詢（JSON，沒有雙引號），並繼續在UI上進行迭代。

我們意識到我們正在做點什麼。我們的開發人員很有效率，我們的應用程式很快，我們的使用者很高興 我們全力投入GraphQL。

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

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

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

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

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

只是開始

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