PayPal：如何在你的公司擴展GraphQL？

PayPal：如何在你的公司擴展GraphQL？

做者｜Mark Stuart譯者｜王強編輯｜王文婧GraphQL 是 REST API 的一種很是流行的替代方案，目前正在席捲開發人員的世界！去年，PayPal 將 GraphQL 引入了技術堆棧，完全改變了開發人員思考數據、獲取數據和構建應用程序的方式。本文做者在一年前曾寫過一篇 GraphQL 最佳實踐的文章，當時受到了廣大讀者的歡迎。這篇文章一樣也是一篇精彩的總結，能夠看成公司部署 GraphQL 的指南。

圖源：graphql.org

咱們在 PayPal 構建 GraphQL API 時得到了一系列最佳實踐和觀察總結，這篇文章就是其中之一。

一年前，咱們寫了一篇《GraphQL：PayPal Checkout 的成功案例》，內容涵蓋了咱們從 REST 到 Batch REST 再到 GraphQL 的發展歷程。自那時以來不少事情都改變了！這篇文章涵蓋了咱們在 PayPal 擴展 GraphQL 時學到的全部知識，並可做爲你在公司部署 GraphQL 的指南。

《GraphQL：PayPal Checkout 的成功案例》：https://medium.com/paypal-engineering/graphql-a-success-story-for-paypal-checkout-3482f724fb53

一年前，使用 GraphQL 的產品不多。雖然咱們在 PayPal Checkout 上取得了成功，但那時尚未相關的基礎架構、工具、培訓或支持。儘管存在這些缺陷，但 GraphQL 的發展仍像火箭通常一飛沖天。在撰寫本文時，咱們已經有 50 多個不一樣的產品在使用 GraphQL！

短短 2 年內，PayPal 使用 GraphQL 的產品從 3 種增長到 52 種。

這項新技術的應用速度 很快，咱們仍在努力跟上步伐。與其餘技術變革同樣，企業級擴展的重點並不在於水平擴展，或爲服務器 / 雲計算投入大量資金。擴展人員、工具鏈和流程是最具挑戰性的。

瞭解本身

在部署 GraphQL 以前，重要的是要深刻了解你所在的公司，理解大家的身份，大家在作些什麼，以及大家的長處與不足。

在 PayPal，咱們的產品使用 JavaScript 構建。前端採用 React，後端則是 Node.js。技術棧中還有數百個 Java REST 服務和一些 C++ SOAP 之類的服務。

PayPal 是最先使用 Node 的公司之一，並經過 NodeDay 之類的活動，以及與 The Node Firm 和 NodeSource 的合做，在業界打響了 Node 的品牌。

2014 年，PayPal 的首個 NodeDay。

2013–2015 年，PayPal 遷移到了 Node。Node 改變了整個公司，改善了咱們製造和運輸產品的方式。過去，一項簡單的內容更改須要數週時間才能部署爲單個單體 C++ 應用。現在，開發人員只須要幾分鐘時間就能夠實驗、迭代和推出新的產品功能。

https://vimeo.com/82577994

這不是一晚上之間發生的轉變，也不是偶然的結果。在 Node 融入 PayPal 以前，Bill Scott 提出了使用 LeanUX 構建產品的願景，其中迭代和學習是核心要素。在 LeanUX 中，UI 數據是實驗性、一次性的。若是實驗效果不佳，那就不斷迭代！Node.js 是其成功的關鍵所在。

Kraken.js

2014 年，咱們推出了 Kraken，這是 Express 上的一組庫，旨在經過可配置的中間件、默認安全設置、一個 dust.js 渲染器和內容本地化來爲你的應用「提供一些幫助」。自那以來，Kraken 的大部分武器都消失了。咱們仍使用可配置的中間件和默認安全設置，但與 Web 應用程序相關的全部內容自 2014 年以來發生了不少變化。如今，團隊正在構建客戶端 React 應用，應用程序是部署到 CDN 的靜態文件包，而不是在服務器集羣中運行的代碼。

對於 API 而言，咱們使用 BFF Schema。儘管它們都是專用的，而且容許開發人員迭代，可是它們緊密耦合在一塊兒，而且不能很好地複用。結果是咱們有不少團隊在反覆迭代和構建相同的事物！構建 BFF API 也不是一件容易的事。它們每每包含許多編排邏輯，其中你須要從 五、十、15 個不一樣的服務中獲取數據，規範化這些響應，丟棄其中 95％的響應，而後將數據映射、過濾、分類爲所需的樣子