近幾年來，互聯網技術趨向於採用前端 JavaScript 框架來構建更好的網頁和移動應用用户體驗。這種變化真的很棒🔥，我個人非常喜歡這些框架給我們帶來的靈活性。

但是，這種靈活性是否已經過頭了呢…

為了真正理解這種情況，我們不妨回顧一下，在 JavaScript 框架誕生之前，應用是如何構建的。

⏳ JavaScript 出現之前的時代…

在最初的幾個前端框架（最著名的包括 AngularJS、Backbone 和 Ember）開發之前，我們通常在服務器上渲染模板，然後將完整的 HTML 頁面發送到瀏覽器。當時流行的框架包括：

• Django（Python）——首次發佈於2005年7月21日。
• Ruby on Rails——首次發佈於2005年12月13日。
• Symphony（PHP）——首次發佈於2005年10月22日。

這些框架圍繞 MVC（即模型-視圖-控制器）應用開發結構的概念展開。模型定義了數據的“形狀”，視圖是展示數據的模板，控制器則“連接”這兩者。

我的意思是，當時也有 JavaScript，但我們討論的更多是像 jQuery 滑塊之類的小工具，以及一些製造完全不必要的彈跳效果的奇特庫…

基於這些框架構建的應用存在一些問題，但總體上，一切都運行得相當不錯。然後有一天，Ryan Dahl 提出了一個絕妙的想法，開始將 JavaScript 用作不僅僅是製作愚蠢動畫的工具。他開發了 Node.js 的第一個版本，使開發者可以在瀏覽器之外的服務器上使用 JavaScript 編寫代碼。

• Node.js——首次發佈於2009年5月27日。

突然間，人們開始欣賞 JavaScript 的強大功能和少量代碼就能完成大量工作的能力。這啓發了其他開發者對 JavaScript 的可能性有了新的認識。人們不僅開始為 Node.js 構建更強大的工具，還開始創建有趣的前端框架。在接下來的幾年中，JavaScript 開發開始呈現雪球效應：

• Express.js（後端）——首次發佈於2010年11月16日。
• Backbone.js（前端）——首次發佈於2010年10月12日。
• AngularJS（前端）——首次發佈於2010年10月20日前。
• Ember.js（前端）——首次發佈於2011年12月8日。

這標誌着應用開發方式的重大轉變。以前由服務器純粹處理的 MVC 框架分為兩個部分——一個服務器處理 MC（模型和控制器）和一個前端客户端使用上述 JavaScript 框架處理視圖。在這些早期框架中，他們還在視圖中包含了模型和控制器。前端和後端都有雙重模型和控制器——現在這聽起來像是大量的代碼！🙇🏽‍

🤦‍ Facebook 遇到了問題

大家都很高興。一切都運行良好，一旦你花幾個小時來理解它，就會相對容易理解。

然後發生了一些事情…

Facebook 的發展迅速，成為世界上最大的網絡應用。可以想象，成為最大的網絡應用帶來了一些挑戰。其中一個最大的頭痛問題是：在標題欄顯示正確的通知數量。

隨着人們在 Facebook 應用中進行操作，這些小的通知應該相應地更新。但這往往不是這樣。我不知道你那時是否在使用 Facebook 或者你是否還記得，但這些通知總是出錯……問題在於，對於網絡應用來説，很難識別應用的一個部分（例如，當你讀取一條消息時）的變化，並在另一個區域顯示這一變化（例如，將未讀通知減少一個）。

這不是世界上最糟糕的事情——通過重新加載頁面可以解決——但 Facebook 有超過 1,000 名充滿熱情的員工，決定是時候做點什麼了。因此，他們重新思考了前端框架處理信息的方式，並決定創建他們自己的框架；React。

• React（前端）——首次發佈於2013年3月。

這個新框架擅長渲染 HTML，但也非常基本，並沒有太多關於“如何”開發應用的指導。因此，他們還推出了 Flux，最終演變為我們所稱的 Redux（重做 Flux）。下面是 2014/2015 年 Flux 網站上的一個視頻。該視頻試圖解釋 Flux 和 React。

🍐 …然後事情開始變得糟糕

Redux 的工作方式本質上是將應用的所有動態信息存儲在一個 JavaScript 對象中。每當應用的某個部分需要顯示一些數據時，它會從服務器請求這些信息，更新單個 JavaScript 對象，然後向用户顯示這些數據。通過將所有信息存儲在一個地方，應用始終顯示正確的信息，無論你在哪裏查看。這解決了 Facebook 的通知問題。

所以突然間，有了一個新的框架來構建應用；React Redux 實現。Facebook 解決了他們的問題，而且每個人都過上了幸福的生活…對嗎？

✋ 並非如此。

問題在於，人們（包括我自己）開始使用單一對象來存儲他們的所有信息——服務器提供的每一條數據。當然，這確保了所有信息都是最新的，但它也帶來了三個主要缺點：

1. 它需要大量額外的代碼才能正常工作，這消耗了你所有的時間。
2. 通過將所有代碼放在一個地方，你還引入了“陳舊數據”的概念，這意味着你的應用中可能會出現以前狀態的不必要數據。
3. 新開發者的學習曲線極高，隨後使得前端網頁開發非常難以被新開發者採用。

我們設法將向用户顯示數據的相對簡單任務，從 2005 年的 MVC 框架的幾個簡單模板，變成了前端應用的龐大系統，前端的代碼比後端多了10倍。例如，我最近開發了一個簡單的應用，並使用 WakaTime 來衡量我在編碼上花費的時間。這是結果：

• React Redux 前端倉庫——32 小時。
• Express + Mongoose 後端倉庫——4 小時。

你是認真的嗎？🤯 我在前端花的時間是後端的8倍。讓我們深入瞭解為什麼需要這麼多額外代碼。以下是我需要遵循的步驟，以便將基本數據獲取調用（例如，獲取所有用户）添加到我的前端倉庫中。

🚧 警告：以下步驟非常技術性，如果你迷失了也不用擔心。

1. 創建顯示用户列表的組件（這裏沒有問題）。
2. 創建對 API 的 fetch 調用。
3. 在狀態中添加一個新字段。
4. 添加一個新的動作，該動作將數據更新到狀態中。
5. 添加一個新的 thunk 方法，這個方法執行 fetch 調用然後使用我們的新動作更新狀態。
6. 使用 connect() 將 thunk 函數添加到我們的組件中，這會將其包裝在一個 dispatch 函數中。
7. 再次使用 connect() 從 Redux 狀態中提取數據。
8. 在我的組件的 prop 類型中聲明 thunk 函數和提取的數據字段。
9. 在 componentDidMount() 函數中調用 thunk 方法。
10. 最後在 DOM 中渲染數據。

天哪… 10個步驟… 回到 Ruby on Rails 的好時光，我所需要做的就是將數據給我的 HTML 模板，然後砰的一聲！它會產生相同的結果。我意識到需要改變一些事情。

☝️ 一種新的方法

Redux 非常適合解決保持前端應用同步的問題，但它自己也帶來了問題（如前所述）。當你想一想；Redux 究竟給我們帶來了多少額外的功能？

本質上，我們重寫了整個前端，以解決一些瑣碎的問題…

Facebook 也意識到了這一點，並實際上開始研究一種名為 GraphQL 的新技術來幫助解決這個問題。GraphQL 目前是一個熱門話題，但我不確定是否真的有人理解為什麼它如此酷炫。

GraphQL 不 像 Redux 那樣。再次，Facebook 提供了一個了不起的產品，但未能清楚地表達為什麼這個珍貴的產品如此重要；因此我花了最後幾分鐘給你一些背景。

總之，GraphQL 是一輛車，Redux 是一匹馬。

什麼？Redux 怎麼是馬？

我將兩者描述為馬和汽車的原因是；你絕不會認為馬與汽車相似——一個是有四條腿的活生生的動物，另一個是有輪子的機器。然而，它們都試圖實現相同的最終目標，即將人帶到他們需要去的地方。汽車在街道上行駛，使用燃料，而馬是一種雄偉的動物，可以跳過岩石。兩者都有不同的優勢和用例，但總的來説；汽車會比馬更快地把你帶到終點。

那麼，GraphQL 是什麼？

官方文檔將 GraphQL 描述為“API 的查詢語言”，這非常不清楚。他們所説的查詢語言的本質是它實際上用潛在的數百個 HTTP 端點替代了一個 API。由於這項技術還很年輕，文檔和支持技術仍有些難以理解；因此，這裏也有一個學習曲線。為了幫助理解，這裏是一個例子。

GraphQL 將替換諸如以下的端點：

• GET /users/1234567890
• POST /cars
• PUT /example/endpoints

用自定義查詢替換，這些查詢只在你需要時創建。例如：

{  user(id: "1234567890") {    name,    email  }}

將返回：

{  "user": {    "name": "Luke Skywalker",    "email": "luke@iamyourfather.com"  }}

但等一下——自定義查詢… 這將花費很長時間來實現。~ 你的想法。

實際上並非如此。原因是；通過只請求你需要的數據，你突然不需要發出那麼多服務器請求，這意味着你不需要編寫那麼多代碼來處理這些服務器請求。因此，你最終節省了大量你不需要實現的代碼的時間。

🤷‍ 但這如何取代 Redux？

另一個很好的問題，謝謝你的提問。簡單地説，它不會。然而，它確實做的是鼓勵你不將所有信息存儲在 Redux 提供給你的單一對象中。這是因為每個查詢都是專門設計來只獲取應用的一部分數據——而不是整個應用的數據。將特定於應用的一個部分的信息存儲在整個應用的數據源中，是一種反模式（而且根本不合邏輯）。

通過使用 GraphQL，你消除了對 Redux 的依賴，從而去除了大量不必需的代碼。

還有一點需要注意的是；Redux 和 GraphQL 可以在一個應用中共存。這很有幫助，因為如果你已經實現了 Redux，你可以慢慢地將 GraphQL 集成到你的 Redux 應用中。

使用 Redux 然後變成一種選擇。用它來解決一些瑣事並帶來所有它的開銷和問題，或者用別的東西替換這些任務。

好的，那麼你用什麼來代替呢？

Redux 是當時解決問題的好方法。然而，自從它問世以來，網頁開發產業已經飛速發展，隨着這種發展，網絡套接字的引入和改進也隨之而來。

網絡套接字是服務器和客户端之間的開放連接，使服務器能夠告訴客户端何時特別更新數據。猜猜怎麼着？GraphQL 在名為訂閲的功能中直接支持網絡套接字。因此，我們可以使用這些訂閲來更新我們希望保持同步的應用部分。

主要區別在於；與其讓客户端告訴我們需要更新什麼（使用 Redux），不如讓我們的服務器告訴客户端數據必須更新。這給我們帶來了同樣的結果。

• 源自：https://hackernoon.com/goodbye-redux-26e6a27b3a0b