PayPal 大規模採用 GraphQL 的探索和實踐

作者 | Shruti Kapoor

譯者 | 張健欣

策劃 | 蔡芳芳  

1 如今 GraphQL 在 PayPal 的狀態

我們通過構建收銀臺體驗開啓了我們的 GraphQL 採用之旅。當 我們用 GraphQL 構建收銀臺應用程序 時，我們看到了採用 GraphQL 的巨大好處，這成爲我們的指路明燈。我們構建了更多的應用程序，提供了基礎設施支持，發佈了一個公共 GraphQL API，並在全公司提供了培訓和學習材料。我們還建立了一個標準機構，提供了一個 GraphQL 工具 fanny pack，並構建了示例應用程序來幫助團隊開始使用 GraphQL。

如今，PayPal 的多個生產應用程序都在使用 GraphQL。現在，使用 GraphQL 構建新的 UI 應用程序已經成爲默認模式。許多現有應用程序正在遷移到 GraphQL。GraphQL 正被身份（Identity）、支付（Payment）、合規性（Compliance）等常見平臺使用，以在所有 PayPal 產品中提供一致的體驗。我們的 API 開發人員已經開始使用 GraphQL 來構建 API。Braintree 發佈了它的 公共 GraphQL API。

在 GraphQL 的幫助下，我們已經能夠彌合面向前端應用程序的後端（BFF，backend for frontend）和後端 API 功能之間的差距，因爲 GraphQL 可以作爲下游 API 的編排層，執行後端 API 的功能，並充當 UI 應用程序的 API 接口。我們正朝着統一的 GraphQL 網關邁進，以支持整個公司。

2 爲什麼 PayPal 需要 GraphQL?

當我們選擇 GraphQL 時，我們正在尋找一種技術來幫助我們解決以下問題：

• 過度獲取的數據：我們的 REST（代表性狀態傳輸）APIs 發送了客戶端需要的部分響應和一些無關數據。由於 REST API 中的服務器決定了數據的形狀，我們的 UI 團隊花費了大量時間在客戶端過濾和解析數據，通常使用諸如 Redux 之類的庫來格式化和存儲數據。使用 GraphQL，客戶端可以請求一組字段，並準確地取回這些字段，從而無需在客戶端進行數據格式化和重塑。這大大加快了我們交付 UI 功能的速度，並且使我們的應用程序更輕量。

• 避免多次請求：通常，爲了調用一個需要特定參數的端點，例如/getProfileById/{id}，我們必須預先請求調用其它端點，例如getUser{username}來返回id 等參數。這是一個問題，因爲我們爲了獲取一條信息進行了多次往返請求。GraphQL 幫助解決了這個問題，因爲它允許我們在一次往返中獲取所需的一切。

• 使客戶端保持最新：我們在 REST API 中大量使用 API 版本號。任何時候我們有突破性的改變，我們都會將其發佈爲一個新的 API 版本。我們面臨的問題是，當我們構建一個新版本時，與舊版本集成的客戶端如果不與新版本重新集成，就不會收到這些更新。有時，新版本中的文檔或參數會發生更改。有了 GraphQL，我們可以發送更新，客戶端不再需要擔心版本的更新。由於所有更新都發布到了 GraphQL 中的一個端點，因此客戶端可以在需要時獲取更新的資源，而無需重新集成到新版本。

• 集成時可以自由使用任何編程語言：原來 Braintree 並沒有公共 API。我們支持服務端 SDKs 和客戶端 SDKs。挑戰在於我們沒有所有語言的服務器 SDKs。許多商戶出於各種原因不想使用 SDKs。我們決定在服務端上爲商戶提供更好的 API。這個新的 GraphQL API 提供了強大的控制能力、靈活性、可移植性、可維護性以及在集成時選擇任何語言的自由，並提供了我們全球支付平臺的可擴展性。您還可以在 API 發佈後立即獲得更新，而無需更新 SDK。

• 統一體驗：PayPal 中的每個流程都有自己的 NodeJS 應用程序，每個團隊都有自己的 ReactJS 實現。我們希望提供一個層來提供統一的前端體驗，同時爲我們提供一個後端來協調 API。

• 對於那些沒有領域知識的人來說，易於集成：在我們的 Identity 團隊中，我們希望在使用我們的服務時提供統一的體驗，而不需要 PayPal 系統的領域知識。我們希望控制我們所有系統的身份，並提供一種安全的方式將 PayPal 子系統賬戶轉換爲 PayPal 賬戶。

• 字段和方法級檢測：我們有內部檢測工具，可以顯示端點花費的時間和使用的參數，但是很難找到使用的字段。如果沒有這些信息，我們就無法知道某個字段是否可以安全刪除，或者是否仍在使用。使用 GraphQL，我們可以獲得字段級的檢測，並清楚瞭解哪個解析器花了多長時間、常見錯誤以及調用了哪些字段。這個字段級檢測有助於智能地棄用不再使用的字段。

• 與 API 集成時開發人員體驗不一致：在 REST API 中，不同團隊對同一變量有不同的約定，例如 user、username, 使得理解 API 變得更加困難。使用聯邦 GraphQL，所有團隊共享同一個 schema，因此更容易識別重複項並使變量命名一致。

• 更容易測試：Apollo Client 等 GraphQL 工具可以更容易地在 React 等 UI 中添加 GraphQL 查詢。它有助於保持代碼位於同一位置，並有助於調試和分離關注點。它提供了一種乾淨的開發人員體驗，並提高了代碼的可測試性。

• API 探索：我們花了很長時間瀏覽 API 文檔，並弄清楚特定字段使用哪個端點。一旦我們有了一個端點，我們就會複製 URL 並在 Postman 中進行嘗試。如果我們遺漏了一個參數，我們將返回文檔並再次搜尋這個參數。這使得使用 API 變得比較困難和耗時。有了 GraphQL，我們就有了 Playground 和 GraphiQL 這樣的工具，它們不僅可以用來探索 API 和瀏覽文檔，還可以在工具中發出請求。這使得開發過程更加順利。

圖片來源：drmakete lab on Unsplash

3 爲什麼我們開始採用 GraphQL？

PayPal 有一套龐大的 REST API，支持應用程序核心功能，並且非常靠近數據庫。GraphQL 在我們的應用程序中用作編排層。它位於前端 UI 應用程序和後端 API 層之間，充當面向前端的後端（BFF）。這意味着 UI 應用程序與 GraphQL 端點對話，這些端點確定要調用哪個下游服務。可以直接在 GraphQL 層構建新功能。一些團隊選擇使用 GraphQL 作爲純編排層，而其它一些團隊使用 GraphQL 作爲業務邏輯層。

收銀臺團隊是第一個率先使用 GraphQL 的團隊。Mark Stuart 在《收銀臺應用程序詳解（Checkout app in this blog post in detail）》中分享了我們採用 GraphQL 的過程。當收銀臺團隊展示他們的應用程序時，我們的工程團隊真正感受到了編排和開發人員生產力提高的好處。這引發了整個 PayPal 的興趣，團隊開始開發在他們的應用程序中使用 GraphQL 的示例程序。

這是新的吸引人的事情。每個人都對這一宣傳感到興奮，但對團隊來說最重要的是，編排下游 API 和爲客戶創建統一體驗有多容易。使用 GraphQL，所有下游的複雜性都可以隱藏，客戶不必擔心找出哪一部分連接到了哪裏。它爲客戶提供了更加連貫的體驗。

團隊開始構建產品，在我們的技術展覽中展示，並使其他人也興奮不已。很快，所有人都感到好奇。一旦我們說服了領導，我們就可以真正起飛了。

4 我們如何擴大 GraphQL 的採用範圍？

當我們開始擴大 GraphQL 的採用範圍時，我們意識到每個應用程序都在試圖解決自己的 GraphQL 問題。通常，各個團隊都在解決相同的問題並重復發明輪子。我們意識到有必要將這些工作統一到一個框架下，因此，我們成立了一個標準機構。我們爲工具、前端和中端示例應用程序、異常處理技術和學習資源提供了支持。

我們構建了有助於支持 GraphQL 採用的工具：

• 我們建立了 GraphQL 標準，用於在內部定義 GraphQL API。這些標準定義了命名約定、GraphQL 類型、請求頭標準、指令標準和異常處理技術。

• 所有 GraphQL 操作都需要指定特殊指令，這些指令描述查詢、突變和字段的所有授權要求。

• 通用庫包括用於日誌記錄的插件、用於數據分類的指令、Apollo 和 playground 的插件、CLI、異常類和 Apollo graph 變體。

• 前端和後端的模板示例程序。

• 學習資源，用於幫助團隊入門 GraphQL。

• Slack 頻道，幫助回答常見問題並創建內部 GraphQL 社區。

擁有一個標準機構和工具非常棒，可以幫助團隊更快地建立他們的圖。然而，我們注意到有些問題仍然存在。我們注意到某個圖偏離了正確的操作方式，例如身份驗證。我們在單個圖中失去了對認證流程的控制。我們還認識到，擁有多個圖會使 schema 共享更加困難。我們希望提供一個統一的入口點，共同管理 schema，以全局方式對數據建模，並提供一種重用類型的方式。這就是促使我們使用 Apollo Federation 構建了一個單圖網關的原因。

5 採用 GraphQL 有哪些優勢？

我們能夠協調周邊服務，並將一個 PayPal 子系統的賬號轉變爲一個 PayPal 賬戶，這很讓我們自豪。我們最初發布了我們的 Braintree API，我們能夠很快完成它。交付速度更快，GraphQL 能夠報告使用了 schema 的哪一部分。我們已經看到的 GraphQL 的主要優勢有：

• 開發人員生產力：GraphiQL 和 Playground 等工具非常適合使用 API 的同時瀏覽文檔，而無需藉助其它任何工具（如 Postman）。

• 可以訪問整個 schema：由於所有操作（查詢和更改）都是在同一個端點，因此訪問 API 支持的所有操作變得更加容易。

• 團隊協作：與 GraphQL API 並行構建 UI 有助於團隊協作。由於 GraphQL schema 需要預先構建，後端工程師和前端工程師一起工作，從而減少了信息隔閡。

• 範式轉換：由於 GraphQL 要求採用設計優先的方法，我們在啓用業務用例時考慮 GraphQL，並在考慮客戶的情況下構建 API。

• 更快的交付速度：我們能夠更快地交付功能。我們能夠擺脫許多彎道，它們使得提供功能更新和保持功能對等變得更難。以前，我們必須用我們的商戶使用的每種語言交付一個 SDK。現在，我們可以只提供一個 GraphQL 端點，商戶無論使用哪種語言都可以與之集成。

• 簡化統一：內部客戶端和周邊客戶端不再需要擔心內部系統的複雜性，也不需要確定調用哪個 API。GraphQL 層將複雜性隱藏在幕後。

• 分析：對特定字段的單個請求花費的時間進行檢測。

• 曝光和招聘：社區中的許多人對 GraphQL 感到興奮，它幫助我們吸引人才加入 PayPal。我們的團隊成員很高興能在社區中分享他們的學習成果，並一直在會議上發言、撰寫博客文章和製作教學資源。Vishakha Singh 就使用 GraphQL 在 PayPal 構建更快的收銀臺體驗進行了演講。Rohit Basu 談到了 用 Kotlin 和 GraphQL 工作。我們在 JS @ PayPal 公開會 上多次討論了我們是如何在各種應用程序中使用 GraphQL 的。

6 我們面臨哪些挑戰？

圖片來源：Possessed Photography on Unsplash

我們仍在創建一種標準方法來應對 GraphQL 技術中的挑戰，如異常處理、身份認證、文件處理和批處理。

各個團隊都在獨立地構建他們自己的圖，這會導致重複工作、不同的異常處理和呈現方式，以及與處理身份認證標準方式的偏差。

我們仍在整合內部工具。由於這些工具很多依賴於 API 響應的狀態碼——200、400、500 等等，因此我們很難將 GraphQL 響應（都是 200）映射到這些工具。

PayPal 的 GraphQL 增長非常快。許多團隊構建了他們自己的方法來處理異常，解決 GraphQL 問題，並對內部日誌系統進行檢測。在它發展之後，我們通過添加內部插件和中間件來提供支持，以規範化錯誤處理、檢測和減少內部網絡聊天，但我們希望能夠更快地構建支持。

我們對單圖方案的採用速度很慢。各個團隊必須改變他們目前製作應用程序的許多行爲，才能採用單圖，增加了交付過程和時間。挑戰在於告訴人們，現在我們有規則可以添加到圖中，但要讓他們有動力使用單圖。Joey Nenni 在 JS @ PayPal 上發表演講，談到了我們實現單圖的方案，以及克服這一挑戰的潛在解決方案。

7 我們如何說服我們的工程和領導團隊？

我們的前端開發人員立即看到了使用 GraphQL 的好處。說服在 UI 團隊中工作的後端開發人員也很容易。他們理解使用 GraphQL 進行編排的力量。對於核心平臺 API 團隊，我們還沒有完全說服他們。當我們介紹 GraphQL 概念時，有時我們被告知 REST 也可以這樣做。是的，它可以，我們也可以使用 REST 複製 GraphQL 所做的事情，但最後，我們只是在重新創建 GraphQL。我們還沒有得到所有前端或後端開發人員的完全認證，但是我們的 REST API 和 GraphQL API 可以共存。我們學會了不操之過急，一點點來。

圖片來源：Christoffer Engström on Unsplash

爲了說服我們的領導，我們知道僅僅關注 GraphQL API 的性能是不夠的。編排的 GraphQL API 的性能取決於它所使用的 API。GraphQL API 的速度僅與最慢的下游 API 的速度相同。相反，我們將重點放在開發人員的生產力和交付產品的時間上。我們演示了使用 GraphQL 可以幫助更快地構建產品，提升團隊協作，並使文檔更容易瀏覽。當我們向我們的團隊介紹 GraphiQL 和 Playground 工具時，他們立刻看到了使用 GraphQL 端點和 playground 工具來在瀏覽文檔時發出請求的好處。

我們演示了 GraphQL 如何幫助提高內部和外部開發人員的生產力，GraphQL 如何幫助減少交付功能的時間，以及我們如何能夠向客戶端隱藏複雜性。使用 GraphQL，我們不必爲每個平臺編寫多個 SDK。我們構建一次 API 就可以了。沒有 GraphQL，我們不知道商戶正在使用哪些字段以及調用了哪些端點。我們在 KPI 上沒有指標，例如首次集成到生產中。通過 GraphQL，我們能夠展示我們的學習、工具和字段級別的監測情況。

8 你如何開始在自己的公司採用 GraphQL？

1. 當你第一次推測 GraphQL 是否是正確的技術時，構建一個示例應用程序來演示 GraphQL 如何適合你的企業架構是很有幫助的。

2. 帶上團隊——演示你的應用程序並展示使用 GraphQL 的好處，你採用 GraphQL 的經歷，你所看到的好處，以及你在幫助公司其他人方面所面臨的困難。

3. 爲成功建立機構——成立一個工作組，幫助建立標準。爲 GraphQL 建立學習資源、提供指導、構建工具和支持。

4. 讓團隊參與進來——從生產力的角度展示使用 GraphQL 的優勢。每個人都希望更快地發佈產品，並使其更容易與 API 集成。GraphQL 正好提供了這一點。向你的團隊成員和領導演示使用 GraphQL 構建新功能是多麼容易，向現有客戶發送更新是多麼容易，而不必發佈新版本，同時仍然向後兼容。

9 特別鳴謝

圖片來源：Wilhelm Gunkel on Unsplash

這篇文檔是我們寶貴的團隊成員的貢獻促成的。感謝 Mark Stuart、Joey Nenni、Walmik Deshpande 和 Miriam Goldberg，感謝他們願意接受採訪並分享他們的經歷。非常感謝 Mark Stuart 在 PayPal 中領導 GraphQL 的採用，激勵我分享我的 GraphQL 經驗，並激勵我們的開發者社區。

作者介紹：

Shruti Kapoor 是 PayPal 的軟件工程師、freecodecamp 和 codeburst 的作家，寫一些 JavaScript 相關的內容。Twitter：shrutikapoor08

原文鏈接：

https://medium.com/paypal-tech/graphql-at-paypal-an-adoption-story-b7e01175f2b7

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/JeONdEN6swrMHJeSZ89zaQ