採用 GraphQL 的技術經驗：營銷技術活動

• 原文地址：Our learnings from adopting GraphQL: A Marketing Tech Campaign
• 原文做者：Netflix Technology Blog
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Sam
• 校對者：lianghx-319

在以前的博客文章中，咱們對營銷技術團隊的一些應用程序提供了高級概述，咱們這麼作是爲了推進全球廣告業務實現 體量化和智能化，使得廣告能夠經過像紐約時報，Youtube 等網站覆蓋成千上萬的用戶。在這篇博文中，咱們將分享關於咱們更新前端架構的過程和在營銷技術團隊中引入 GraphQL 的經驗。

咱們用於管理建立和裝配廣告到外部部署平臺的核心應用程序在咱們內部被稱爲 Monet。它用於加強廣告的建立和自動化管理在外部廣告平臺的營銷活動。Monet 幫助推進增量轉化，一般是和咱們的產品進行交互，爲全球各地的用戶展現關於咱們內容和 Netflix 品牌的精彩故事。爲此，首先，它幫助擴展和自動化廣告產品，而且管理數百萬廣告素材隊列。其次，咱們借用多種信號和彙總數據（例如瞭解在 Netflix 上的內容流行度）以實現高度相關的廣告。咱們整體目標是確保咱們全部在外部發布頻道的廣告可以很好的引發用戶的共鳴，而且咱們不斷嘗試提升咱們這麼作的有效性。

Monet 和高級營銷技術流程

在咱們開始的時候，Monet 的 React UI 層訪問的是由 Apache Tomcat 服務提供的傳統 REST API。隨着時間的推移，咱們應用程序的發展，咱們的用例變得更加複雜。簡單的頁面須要從各類來源中獲取數據。爲了更加高效的在客戶應用程序中加載這些數據，咱們首先嚐試在後端對數據進行非規範化處理。因爲不是全部頁面都須要全部這些數據，管理這些非規範化(的數據)變得難以維持。咱們很快就遇到了網絡帶寬瓶頸。瀏覽器須要獲取比以往更多的非規範化數據。

爲了減小發送給客戶端的字段數量，一種方法是爲每一個頁面建立自定義端點；這是一個明顯不切實際的想法。咱們選擇使用 GraphQL 做爲咱們應用的中間層，而不是建立這些自定義端點。咱們也考慮過把 Falcor 做爲一個可能的解決方案，畢竟它在 Netflix 的不少用例中展示出很好的成果而且大量的使用，可是 GraphQL 健壯的生態體系和強大的第三方工具庫使得 GraphQL 成爲咱們用例更好的選擇。此外，隨着咱們數據結構愈來愈面向圖形化，使用 GraphQL 最終適配會很是天然。添加 GraphQL 不只解決了網絡帶寬瓶頸問題，並且還提供了許多其餘優點，幫助咱們更快地添加功能。

使用 GraphQL 架構的先後對比。

優點

咱們已經在 NodeJS 上運行 GraphQL 差很少六個月了，而且它已經被證明能夠顯著提升咱們的開發速度和整體提高頁面加載性能。這裏是自從咱們使用 GraphQL 實踐給咱們帶來的一些好處。

從新分配負載和有效負載優化

一般，某些機器比其餘機器更適合作一些任務。當咱們添加了 GraphQL 中間層時，GraphQL 服務器仍然須要調用和客戶端直接調用的相同的服務和 REST API。如今的區別在於大多數據在同一數據中心的服務器之間流動。這些服務器和服務器之間的調用是很是低延遲和高帶寬的，比起直接從瀏覽器發起網絡請求有 8 倍的性能提高。從 GraphQL 服務器傳送數據到客戶瀏覽器的最後一段雖然還是一個慢點，但至少減小成單個網絡請求。因爲 GraphQL 容許客戶端只選擇它須要的數據，因此咱們最終能夠獲取明顯更小的有效負載。在咱們的應用程序中，頁面以前要獲取 10M 的數據，如今接收大約 200KB 便可。頁面加載變得更快，特別是數據受限在移動網絡上，而且咱們的應用使用的內存更少。這些更改確實以提升服務器利用率爲代價來執行數據獲取和聚合，可是每一個請求所花費的額外一點服務器毫秒時間遠比不上更小的客戶端有效負載。

可複用的抽象

軟件開發者一般但願使用可複用的抽象而不是單一目的方法。使用 GraphQL，咱們定義每段數據一次，並定義它與咱們系統中其餘數據之間的關係。當消費者應用程序從多個源獲取數據時，它再也不須要擔憂與數據鏈接操做相關聯的複雜業務邏輯。

考慮接下來的例子，咱們在 GraphQL 中只定義實例一次：catalogs（類別）、creatives（素材）和 comments（評論）。如今咱們能夠由這些定義建立多個頁面視圖。客戶端上的一個頁面（類別視圖）定義了它想要全部的評論和素材在一個分類裏，而另外一個客戶端頁面（素材視圖）想要知道素材相關聯的類別，以及全部和它相關的評論。

GraphQL 數據模型的靈活性，用於表示來自相同底層數據的不一樣視圖。

同一個 GraphQL 模型就能夠知足上述兩個視圖的需求，而不用作任何服務器端的代碼修改。

鏈式系統

不少人專一於單一服務器裏的類型系統，但很難有跨服務的。一旦咱們在 GraphQL 服務器中定義了實例，咱們使用自動代碼生成器工具爲客戶端程序生成 TypeScript 類型。咱們的 React 組件屬性接收類別以匹配組件正在進行的查詢。因爲這些類別和查詢也是針對服務器模式進行驗證的，所以服務器的任何重大更改都將被使用該數據的客戶端捕獲。將多個服務器和 GraphQL 連接在一塊兒並將這些檢查掛載到構建過程當中，可讓咱們在發佈代碼前捕獲更多錯誤。理想狀況下，咱們但願從數據層一直到客戶端瀏覽器層都是具備類型安全性的。

從數據庫到後端到客戶端代碼的類型安全。

DI/DX — 簡化開發

當建立客戶端應用程序時廣泛須要考慮 UI/UX，可是開發者界面和開發者體驗通常只是側重於構建可維護應用程序。在使用 GraphQL 以前，編寫一個新的 React 包裝組件須要維護複雜的邏輯，以便爲咱們所需的數據發起網絡請求。開發者須要關心每部分數據之間的依賴，數據該怎麼緩存，以及是否作併發或隊列請求，還有在 Redux 的什麼位置存儲數據。使用 GraphQL 的查詢封裝（wrapper），每一個 React 組件只需描述它所須要的數據，而後由封裝（wrapper）去關心全部這些問題。這樣就會是更少的引用代碼和更清晰的數據與 UI 之間的關注點分離。這種定義數據獲取的模塊可讓 React 模塊更容易理解，而且可以爲部分描述文檔提供服務知道組件具體在作什麼。

其餘優點

咱們也留意到其餘一些小的優點。首先，若是任何 GraphQL 的查詢解析器失敗了，已經成功的解析器仍然會返回數據到客戶端渲染出盡量多的頁面。其次，因爲咱們更少的關心客戶端模型，後端數據模型就簡化了不少，在大多數狀況下,只需提供一個 CRUD 接口的原始實體。最後，基於 GraphQL 的查詢會自動爲咱們的測試進行存根轉變，測試咱們的組件也會變得很簡單，而且咱們能夠把解析器從 React 組件中獨立出來進行測試。

使用痛點

咱們遷移到 GraphQL 是一個直截了當的過程。咱們構建的大多數用於作網絡請求和傳輸數據的基礎架構在不作任何代碼修改的狀況下能夠很容易在 React 應用和咱們 NodeJS 服務之間作到可傳遞。咱們甚至最終刪除的代碼比咱們加的多。可是在遷移到任何新的技術這條路上，總會有一些須要咱們越過的障礙。

自私的解析器

因爲 GraphQL 裏的解析器定義爲獨立運行的單元，而不用關心其餘解析器在作什麼，咱們發現他們會對相同或相似的數據發起不少重複的網絡請求。咱們經過將數據提供者包裝在一個簡單的緩存層中來避免這種重複，該緩存層將網絡響應存儲在內存中，直到全部解析器都完成。緩存層還容許咱們將多個對單個服務的請求聚合爲一次對全部數據的批量請求。解析器如今能夠請求他們須要的任何數據，而沒必要擔憂如何優化獲取數據的過程。

添加緩存以簡化來自解析器的數據訪問

咱們編寫的繁雜網絡

抽象是提升開發人員效率的好方法 —— 直到出現問題爲止。毫無疑問，咱們的代碼中會有bug，咱們不想用中間層混淆(bug 產生的)根本緣由。GraphQL 將自動編排對其餘服務的網絡調用，對用戶隱藏複雜性。雖然服務器日誌提供了一種調試方法，可是它們仍然比經過瀏覽器的 network 選項卡進行調試的天然方法少了一步。爲了讓調試更簡單，咱們直接將日誌添加到 GraphQL 響應有效負載中，它公開了服務器發出的全部網絡請求。當啓用調試標誌時，你將在客戶端瀏覽器中得到與瀏覽器直接進行網絡調用時相同的數據。

拆分類型

傳遞對象是面向對象編程（OOP）的所有，但不幸的是，GraphQL 將對這個範式形成衝擊。當咱們獲取部分對象時，這些數據不能用於須要完整對象的方法和組件中。固然，你能夠手動強制轉換對象並抱着最好的但願，可是你將失去類型系統的許多好處。幸運的是，TypeScript 使用了 duck typing（譯者注：鴨子類型，關注點在於對象的行爲，能做什麼；而不是關注對象所屬的類型。duck typing），因此只須要對它們真正須要的對象屬性方法進行調整是最快的修復方式。雖然定義更精確的類型須要作更多的工做，可是整體上確保了更大的類型安全性。

接下來是什麼

咱們仍然處於探索 GraphQL 的早期階段，但到目前爲止都是一種積極的體驗，咱們很高興可以接受它。這項工做的一個關鍵目標是，隨着咱們的系統變得愈來愈複雜，（它）幫助咱們提升開發速度。咱們不但願被複雜的數據結構所困，而是但願在圖形數據模型上進行投資，隨着時間的推移，隨着更多的邊緣和節點的添加，咱們的團隊會更加高效。甚至在過去的幾個月裏，咱們已經發現咱們現有的圖形模型已經足夠健壯，咱們不須要任何圖形更改就能夠構建一些特性。它確實讓咱們變得更有效率。

咱們的可視化 GraphQL 模型

隨着GraphQL的不斷髮展和成熟，咱們期待能夠從社區中使用它構建和解決的全部使人驚歎的東西中學習。在實現級別上，咱們期待使用一些很酷的概念，好比模式縫合，它可使與其餘服務的集成更加直接，並節省大量開發人員的時間。最重要的是，咱們很開心地看到在公司不少團隊發現 GraphQL 的潛力並開始採用它。

若是你已經作到了這一點，而且你也有興趣加入 Netflix 營銷技術團隊來幫助克服咱們獨特的挑戰，看看咱們頁面上列出的空缺職位。

咱們正在招聘！

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。