耐克公司是如何將API切換到GraphQL的？

banq發表於2018-12-23
API

“節省了四周的工程。”
“淘汰了7,500行客戶端程式碼和測試。”
“線上資料減少16倍。”
“更快的移動版本。”
這些是Nike團隊使用了GraphQL以後出現的一些令人興奮的成就。GraphQL於2015年正式釋出，是一個開源規範，為前端Web和移動體驗提供了一種更高效，更強大，更靈活的REST替代方案。GraphQL為客戶團隊提供了兩種正規化轉換。
首先，它支援客戶端 - 伺服器REST模型的翻轉。客戶團隊不是在程式上拼湊出大量的端點和模式本身，而是簡單地在宣告性查詢中跨服務定義他們的確切資料模式需求。這減少了領域模型學習曲線，昂貴的客戶端 - 伺服器網路請求的數量以及資料的過量和不足。
其次，GraphQL的宣告性介面以及我們不斷增長的API圖表促進了客戶端的可重用性。利用相同的共享解析器和API模式的團隊不再需要實現自己的聚合層，從而大大加快了產品上市時間。這幾乎消除了自定義的一次性聚合程式碼，否則需要由每個客戶端平臺和體驗團隊進行冗餘開發，測試和維護。
耐克不斷創新和探索GraphQL，專門的GraphQL團隊被稱為“盛大”的跨組織工作組，目標在耐克的數百個微服務API之上提供一套通用的無狀態聚合閘道器。此外目標是：
  • 透過減少網路呼叫和資料編排，縮小客戶端，縮短產品上市時間; 不再需要構建和支援一次性聚合層的開銷
  • 透過可重用的GraphQL架構和解析器提供共享功能
  • 透過減少客戶端應用程式所需的網路呼叫次數來提高客戶端效能


Nike透過GraphQL創新的團隊包括Checkout，Cart，Wishlist，Nike App，CMS，Nike By You（NikeID），僅舉幾例。以下是團隊使用開源API查詢語言的經驗的簡要說明。

Nike.com Checkout
Checkout團隊於2017年底開始了他們的GraphQL之旅，為消費者提供最佳的Nike.com雲結賬體驗。團隊需要在眾多微服務中聚合資料。早期的GraphQL概念證明很快證明了他們希望的價值。

當Nike.com購物車和收藏單也需要聚合時，很明顯是時候將GraphQL POC發展成一個可以重複使用的通用無狀態閘道器。而不是為每個功能單獨開發和維護自定義各自一套GraphQL實現。

GraphQL工作組和Checkout團隊開始合作，提供一組水平可伸縮的無狀態GraphQL聚合閘道器。一旦Nike微服務被一個團隊整合，它就成為Nike更大圖表的一部分，可以被所有耐克的網路和移動體驗重複使用。

使用相同的底層模式後，Cart和Checkout團隊能夠透過Web儲存共享資料，以允許使用者在Web應用程式之間導航時跳過冗餘的API呼叫。這大大提升了使用者的效能。

這項初步工作為生產GraphQL閘道器奠定了基礎，該閘道器在2018年末被幾個額外的雲體驗所利用。

GraphQL閘道器提供了許多好處，包括：

  • 可重用性：GraphQL API整合不是為每種新功能體驗構建自定義的一次性聚合層，而是跨經驗重用。這大大加快了上市時間，更快地為消費者服務。
  • 體驗優先的API：Checkout團隊能夠以宣告方式定義他們在微服務中所需的精確資料。這可以提高客戶端效能，因為客戶端和伺服器之間傳輸的資料更少，往返次數更少
  • 更輕鬆的客戶：隨著越來越多的服務變為無狀態，客戶變得更有條理。這導致更厚的客戶端將更多程式碼推送到前端。GraphQL簡化了Checkout的前端狀態管理，加速了他們的團隊並使連續更新變得更加容易。
  • 可觀察性：計劃的GraphQL工具允許一定程度的深入分析和視覺化。團隊可以輕鬆地觀察底層服務如何執行到客戶端請求的各個資料欄位。服務團隊也將更清楚地瞭解如何以及誰在呼叫他們。
  • 自動化：開源社群工具允許基於GraphQL模式自動生成模擬和測試。該計劃還將從我們的微服務OpenAPI 3 Swagger文件中自動生成GraphQL架構。（機器人來了！）

耐克APP
Nike App團隊利用相同的共享解決方案快速整合下游API，Nike App及其本地化產品推薦的目標是根據消費者的實時位置附近提供個性化的上下文建議。
網路呼叫特別昂貴，並且移動應用程式的電池壽命也在不斷消耗。最佳做法是減少API呼叫的數量，以儘可能少的網路請求提供所需的使用者體驗。在微服務領域，這是一個挑戰。
解決方案是使用GraphQL聚合閘道器為Nike App提供單次網路呼叫，跨三個巢狀微服務檢索資料，併為重用使用此無狀態閘道器的其他團隊提供的API整合。
這對Nike App來說是三贏：

  1. 程式碼縮減：單個GraphQL API呼叫減少了在許多微服務中編排呼叫所需的數百行客戶端程式碼。
  2. 可重用性和一致性：iOS和Android Nike應用程式都能夠重用相同的閘道器進行資料聚合。
  3. 效能提升：降低了昂貴的客戶端網路請求。此外，GraphQL透過定製對其移動體驗要求的響應來消除資料的過度獲取。Nike App將其有效載荷從500KB減少到11KB！


CMS
CMS團隊在將他們的平臺從Aurelia遷移到React（另一個流行的Facebook OSS庫）時開始使用GraphQL 。由於Nike的微服務架構，之前平臺的一個難點是需要多個API呼叫。該團隊知道聚合層可以減少網路呼叫並大大簡化前端開發過程。當他們決定遷移到React時，他們也將GraphQL實現為他們的聚合層。
如今，CMS團隊使用GraphQL彙集了超過17種微服務，以提供優質的內容創作體驗。以前，在具有較少服務的單一體系結構中，CMS團隊將管理前端多個API呼叫的非同步性質，呼叫每個服務並一次處理響應，因為它們在承諾鏈中解析。使用GraphQL，CMS前端只需要發出一個請求來檢索針對前端體驗最佳化的資料模型。

Nike定製團隊
Nike的定製團隊於2017年開始了他們的GraphQL之旅，以簡化定製實驗室（一個內部運營Web應用程式）與複雜的後端微服務網路進行通訊的方式。
與CMS團隊類似，NikeID團隊採用GraphQL重構前架構。從包含許多由數百行非同步資料編排組成的模組的大型Redux儲存轉換為基於查詢的宣告式模型。使用Apollo Client，NikeID團隊將GraphQL查詢對映到各自的前端元件，並僅在需要時獲取資料。
在伺服器上，將數十個REST端點組合成一組乾淨的GraphQL查詢和解析器，與過去經常設計的自定義聚合服務相比，感覺自然而直觀。過去的自己單獨定義的聚合層在它們被部署之前基本上是技術債務，很快成為維護的噩夢。下游服務合同將發生變化，將出現新的業務需求，並且維持它們的頻寬有限。藉助GraphQL，該團隊擁有靈活，可重複使用的介面，可滿足他們的資料需求。

耐克 Order Futures Buy，GameDay和API +
發現並確定了這個產品線的資料管理方式中反覆出現的問題。多年來，這些團隊建立了自己的快取產品資料資料庫。他們一次又一次地遇到資料不一致，導致消費者的負面影響。
團隊一致決定使用GraphQL，使用單一，靈活的產品API。
在為GraphQL框架建立了大量概念證明之後，包括Spring Boot / Java實現和Scala / Akka實現，團隊開始使用前面團隊使用的相同NodeJS Apollo Server實現。由於聚合微服務經常會為客戶端引入I / O問題，因為它們必須非同步呼叫許多API，因此NodeJS和JavaScript成為他們的明智選擇。
該團隊使用GraphQL提供更好的使用者體驗。GraphQL允許它們透過精確指定所需的資料模式來返回較小的有效負載。他們的UI不再需要維護一組API來獲取各種資料點。他們的GraphQL實現聚合了五個REST微服務：他們的影像庫服務，複製服務，產品屬性服務，影片庫和技術表服務。該團隊對其第四季度釋出感到興奮，並正在擴充套件以滿足各個團隊的需求。

結論
在耐克，我們痴迷於最佳化消費者之旅 - 旨在為我們的數字生態系統提供優質體驗。我們不斷評估可能改善這些體驗的新技術。隨著軟體行業每天都在生產新技術，重要的是要仔細權衡任何新技術的優勢和採用成本。GraphQL被證明是耐克和我們的消費者的贏家。
跨組織工作組繼續使用Nike API的共享圖表來促進跨體驗的可重用性。隨著域微服務API的整合，任何經驗都可以毫不費力地檢索資料，而無需任何額外的自定義聚合程式碼。隨著耐克的團隊繼續探索利用GraphQL重新定義全球範圍內的耐克購物體驗，請繼續關注。

 

相關文章