在這篇文章中，我們將分享Netflix在這些應用程序的前端架構中引入GraphQL所積累的經驗。

在內部，我們把用于管理廣告創建和組裝的主要應用程序叫作Monet。它用于增強廣告的創建以及自動管理外部廣告平臺上的營銷廣告活動。Monet有助于推動流量增量轉換，增強用戶與產品的互動，并向全世界的用戶展示我們的內容和Netflix品牌。

首先，它有助于擴展和自動化廣告創建以及管理數百萬個廣告素材組合。其次，我們利用各種信號和匯總數據（例如Netflix上的內容流行度）來實現高度相關的廣告。我們的總體目標是使所有外部發布渠道上的廣告都能夠讓用戶產生共鳴，并且不斷嘗試提高有效性。

背景

在剛開始時，Monet的React UI層需要訪問由Tomcat服務器提供的傳統REST API。隨著時間的推移，隨著應用程序的發展，我們的用例變得越來越復雜，即使是一個簡單頁面也需要從各種來源提取數據。

為了更有效地將這些數據加載到客戶端，我們首先嘗試對后端的數據進行非規范化。但這種非規范化變得難以維護，因為并非所有頁面都需要所有數據。我們很快遇到了網絡帶寬瓶頸。瀏覽器需要獲取比以往更多的非規范化數據。

為了減少發送給客戶端的字段數量，一種方法是為每個頁面構建自定義端點，但這很明顯不是一個好的解決方案。我們沒有去構建自定義端點，而是選擇GraphQL作為應用程序的中間層。

我們還將Falcor作為一種可能的解決方案，因為它在Netflix的很多核心用例中已經取得了很好的成果，并且得到了大量的采用，但因為GraphQL強大的生態系統和第三方工具，我們認為GraphQL對我們的用例來說會是更好的選擇。此外，隨著我們的數據結構越來越以圖形為導向，GraphQL最終會變得更加合適我們的用例。引入GraphQL不僅解決了網絡帶寬瓶頸問題，而且還提供了很多其他優勢，讓我們能夠更快地添加功能。

我們已經在NodeJS上運行GraphQL大約6個月，并且它已經被證明可以顯著提高我們的開發速度和整體頁面的加載性能。以下是從我們開始使用它以來給我們帶來的一些好處。

GraphQL優點

重新分配負載和優化有效載荷

通常，某些機器比其他機器更適合用來完成某些任務。當我們引入GraphQL中間層后，GraphQL服務器仍然需要調用與客戶端相同的服務和REST API。現在的區別在于，大多數數據是在同一數據中心內的服務器之間流動。這些服務器到服務器之間的調用具有非常低的延遲，而且帶寬非常高，與來自瀏覽器的直接網絡調用相比，性能提升了8倍。

從GraphQL服務器到客戶端瀏覽器的最后一英里數據傳輸現在減少到了單個網絡調用。由于GraphQL允許客戶端選擇它需要的數據，所以我們只需要獲取更小的有效載荷。

在我們的應用程序中，之前需要獲取10MB數據的頁面現在只需要獲取200KB。頁面加載速度變得更快，特別是在數據受限的移動網絡上，我們的應用程序使用的內存也更少了。這些變更是以提高服務器利用率為代價的，服務器需要進行數據的獲取和聚合，不過雖然犧牲了這額外的幾毫秒服務器時間，卻換來了較小的客戶端有效載荷。

可重用的抽象

軟件開發人員通常希望使用可重用的抽象而不是單一用途的方法。在使用GraphQL時，我們定義了數據以及與數據之間的關系。當消費者應用程序從多個源獲取數據時，不需要操心與數據連接操作相關聯的復雜業務邏輯。

例如，我們只在GraphQL中定義一次實體：catalog、creative和comment。我們現在可以基于這些定義構建多個頁面視圖。客戶端應用程序（catalogView）的一個頁面想要獲得catalog中所有creative的所有comment，而另一個客戶端頁面（creativeView）想要知道creative和相關comment所屬的catalog。

鏈接類型系統

很多人專注于單一服務中的類型系統，但很少關注跨服務。在GraphQL服務中定義了實體之后，我們就會使用自動生成工具為客戶端應用程序生成TypeScript類型。React組件的prop接收類型以匹配組件查詢。由于這些類型和查詢也需要通過服務器schema的驗證，因此服務器的任何重大更改都將被使用數據的客戶端捕獲到。

使用GraphQL將多個服務鏈接在一起，并將這些檢查過程集成到構建過程中，可以在部署錯誤代碼之前捕獲更多問題。理想情況下，我們可以實現從數據庫層一直到客戶端瀏覽器的類型安全性。

DI/DX——簡化開發

創建客戶端應用程序時人們比較關心的是UI/UX，但開發者接口和開發者體驗對于構建可維護應用程序來說同樣重要。在使用GraphQL之前，編寫一個新的React容器組件需要維護復雜的邏輯。

開發人員需要考慮數據之間的相關性、如何緩存數據、是否進行并行調用還是串行調用以及在Redux的什么地方保存數據。在使用GraphQL查詢包裝器后，每個React組件只需要描述它需要的數據，包裝器會處理所有其他問題。這樣樣板代碼更少了，數據和UI之間的關注點也更清晰了。這種聲明性數據提取模型讓React組件變得更容易理解。

其他好處

我們也注意到了其他的一些較小的好處。首先，如果GraphQL查詢的某些解析器失敗，成功的解析器仍然會將數據返回到客戶端，并盡可能多地渲染頁面。其次，后端數據模型得到大大的簡化，因為我們不需要關心客戶端的模型，并且在大多數情況下可以只提供原始實體的CRUD接口。最后，測試組件也變得更容易，因為GraphQL查詢被自動轉換為測試存根，我們可以獨立于React組件測試解析器。

成長的煩惱

基于我們為網絡請求和轉換數據構建的大多數基礎設施，可以輕松地將React應用程序轉到NodeJS服務器上，無需更改任何代碼。我們刪除的代碼比我們添加的還要多。但是，在遷移過程中，我們難免要克服一些障礙。

自私的解析器

GraphQL中的解析器作為獨立單元運行，不需要關心其他解析器，因此我們發現它們對相同或類似的數據進行了很多重復的網絡請求。我們通過為數據提供者提供一個簡單的緩存層來解決這種重復問題，這個緩存層將網絡響應保存在內存中，直到所有解析器處理完畢。緩存層還允許我們將對單個服務的多個請求聚合成一次性請求。解析器現在可以請求它們需要的任何數據，無需操心如何進行優化數據的獲取過程。

我們編織的糟糕的Web

抽象是提高開發人員效率的好辦法…直到出現問題。毫無疑問，我們的代碼中存在bug，我們不希望中間層將bug的根源隱藏掉。GraphQL會自動編排對其他服務的網絡調用，從而隱藏用戶的復雜性。服務器日志可以作為一種調試方法，但仍然不能使用瀏覽器實現這一步的調試。為了使調試更容易，我們將日志直接添加到GraphQL響應有效載荷中，顯示了服務器正在處理的所有網絡請求。在啟用調試標志后，你將在瀏覽器中獲得與使用瀏覽器進行網絡調用時相同的數據。

被破壞的類型

GraphQL破壞了OOP的范式，當我們獲取部分對象時，這些數據不能用于需要完整對象的方法和組件。當然，你可以手動轉換這些對象，但是你會失去類型系統的很多好處。所幸的是，TypeScript支持動態類型，因此我們可以調整方法，讓它們只需要獲得真正需要的對象屬性即可。定義這些更精確的類型需要更多的工作量，但總體上能夠提供更大的類型安全性。

接下來

我們仍然處于探索GraphQL的早期階段，到目前為止，這是一次積極的體驗，我們很高興能夠采用它。我們的關鍵目標之一是在系統變得日益復雜的同時幫助我們提高開發效率。

我們希望在圖數據模型上進行投入，以便隨著更多邊和節點的增加，我們的團隊將變得更加高效，而不是陷入復雜數據結構的泥潭中。在過去的幾個月，我們已經發現現有的圖模型已經變得足夠強大，我們不需要修改圖就可以構建出一些功能。GraphQL確實使我們更有成效。

隨著GraphQL繼續發展和不斷成熟，我們期待從社區學習到更多東西。在實現層面，我們期待使用一些很酷的概念，如模式拼接，這讓與其他服務的集成變得更加簡單，并節省大量的開發時間。最重要的是，讓公司的更多團隊看到GraphQL的潛力并開始采用它是一件非常令人興奮的事情。

英文原文

https://medium.com/netflix-techblog/our-learnings-from-adopting-graphql-f099de39ae5f

總結

以上是生活随笔為你收集整理的Netflix：我们为什么要将GraphQL引入前端架构？\n的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。