技術棧：爲何 Node 是小菜前端團隊的核心技術棧

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬抗，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream。

本系列共 15+ 篇 - 點此連接，此爲第二篇，你們看完轉發下朋友圈我就心滿意足了。

任何能夠用 JavaScript 來寫的應用，最終都將用 JavaScript 來寫。  -- 阿特伍德定律

這篇文章向你們介紹下小菜前端的基建在一步步走過來的過程當中，NodeJS 是如何使用的及扮演了哪些角色，它對於工程師我的，團隊能力，公司研發效率，業務支撐，技術的探索與突破等等到底有什麼實際的意義，以及爲何是它而不是 Python/C++/PHP/Java 成爲了前端團隊的核心技術棧。

被 NodeJS 加速的框架演進速度

2019 年的前端與 2009 年的前端早已經是君住長江頭我住長江尾，短短十年，人是物非，React/Vue 一統天下，Webpack 標配江湖，單純看近 2 年的 【Npm Trends】:

或者參考近 10 年的【Google Trends】：

熱度必定程度反映了社區活躍，和佔用市場的體量，能夠發現 AngularJS 也是經歷了過山車，市場被 React/Vue 不斷侵蝕，那再把 jQuery 加進來看下：

使人瞠目結舌，即使 React/Vue（綠色和紫色） 如日中天的今天，在整個網絡的搜索熱度上，也遠遠低於 jQuery 和 NodeJS，尤爲是 jQuery，雖然它的熱度在持續下降，但依然是整個互聯網中不能忽視的重要組成部分，

雖然早期與 jQuery 同時代還有不少其餘框架類庫，好比 ExtJS/Mooltools/Dojo/Yui/Kissy 等等等等，但它們的體量比起 jQuery 都差之甚遠再也不比較，若是你們把近十年聽到的看到的框架羅列起來，幾十上百都不成問題，生命週期能超過 5 年卻寥寥無幾，尤爲是在 2012 年 NodeJS 在全球推廣到必定規模後，框架的誕生迭代替換更爲快速，因此從框架的生命力來看，jQuery 目前爲止依然是贏家，那它跟 NodeJS 有什麼關係呢？

NodeJS 的持續變熱，jQuery 也在持續走冷，一部分緣由就是 NodeJS 生態基建能力，在之上不斷的生長出來新的框架與解決方案（不限於 AngularJS/React/Vue），也在不斷的蠶食 jQuery 的市場，假若沒有 NodeJS，天然也不可能有新框架的繁榮之態，今天大有可能依然是 jQuery 在一統江湖。

在今天，不管是 Angular/React/Vue/Webpack，從開發體驗、單元測試到打包編譯，脫離了 NodeJS 生態，都沒法正常運轉，NodeJS 就是整個上層建築的物理基礎和配套設施，咱們從宏觀上了解了 NodeJS 對於前端框架進化和保障的重要性。

接下來，就結合小菜前端在 NodeJS 上的建設與你們聊聊它的重要性，2 年來，咱們重度使用 NodeJS 陸續參與了十幾個重要的工具/產品/系統的建設，下面挑選四個有表明性的分享給你們：

小菜前端第一次嚐鮮 NodeJS - APP 熱更新服務

寫一些 NodeJS 自動化腳本，代碼校驗甚至利用 Express/Koa 搭建一些簡單的服務，這些都不能算作真正意義使用 NodeJS，咱們也拋開 ReactNative/Webpack 等前端開發打包編譯須要依賴 NodeJS 這樣的場景，咱們第一次真正意義使用 NodeJS， 就是對 ReactNative APP 開發的熱更新系統，代號神奇博士，服務端框架用的 ThinkJS 框架，那時候是 2016 年中，Scott 尚未入職小菜。

這樣一個熱更新發布系統可讓客戶端 APP 動態更新到增量的代碼包，最原始的更新流程以下圖：

在熱更新系統中，須要針對 iOS/Android 的 IPA/APK 包進行特定操做系統的資源拆包，增量包/原生包存儲，包版本管理，權限管理等功能，這些事情是不太可能讓服務端童鞋好比 Java 童鞋替你作的，只能前端本身作，也只能用 NodeJS 才能快速的開發出來。

系統上線後，整個公司的 App 發版頻率從一個月一兩次（審覈還會被打回）提高到一週三四次，效率至少提高 10 倍，並且用戶的更新體驗獲得質的提高，對於業務/運營/產品/用戶都有極大的價值。

這時候咱們概念裏面的 NodeJS 可能更像是一個特定場景的功能玩具，並無深挖它的重要性和可能性，雖然嚐到了甜頭，但日後的一年多沒有再持續挖掘。

小菜前端第二次嚐鮮 NodeJS - APP 打包平臺

Scott 是從 2011 年開始接觸和使用 NodeJS，從 2013 年後技術棧以 NodeJS 爲主，開始嘗試搭建比較複雜的系統，很是清楚它的優點和短板，在 2017 年下半年開始帶前端團隊的時候，收到了不少的反饋和投訴，主要分爲兩類： APP 更新失敗的問題（在很是高的迭代節奏下） 和先後端協做的接口/聯調問題，針對 APP 更新下失敗的問題，咱們先來還原下當時的開發狀態，你們若是也有多人協做 RN APP 的開發，能夠參考接下來咱們的作法，相信對你有用。

咱們的 APP 當時一共有 5 個 - 宋小菜（對外）、宋小菜司機（對外）、宋小菜供應商（對外），宋小福（對內）、採祕（對內），全部的 APP 都是 RN 開發，都有 iOS/Android 兩個版本，其中對外的是商業開發版本，要發佈到蘋果商店和推送到特定渠道，對內的都是企業包，不對外公開，咱們經過公司本身的網站託管應用供員工安裝。

這些 APP 之間的業務也有必定的聯繫，一般開發宋小菜，也會聯動要修改宋小福或者採祕，在本地開發的時候，須要在每一個包裏面，區分鏈接的是平常測試環境，仍是線上生產環境，還要區分是能夠打印出日誌的 debug 包，仍是非 debug 包，而且最終上線前，再由每一個同窗在本地 Mac 上打出一個包上傳到熱更新平臺，這個流程裏面會出現大量問題，我曾經畫了這樣一張圖給服務端的同窗解釋爲何前端打包 APP 到上線會常常出問題：

這樣就會有不少組合，有的包是要頻繁打的，有的偶爾來幾發，打包的時候要區分：

• 是哪個 APP
• 是打 iOS 仍是 Android 的包
• 是正式環境，仍是平常測試環境
• 打的包要不要開啓熱更新功能，不開啓就不會走線上熱更新流程
• 這個包要不要實時連到本地打一些 log 出來，也就是是否 Debug
• 是在哪一個同窗電腦上打的包

這樣硬組合就能夠打出 64 個不一樣的包，意味着可能須要把配置文件修改 64 次，另外，每一個同窗電腦上的 Mac 操做系統版本會有不一樣，XCode/Gradle 也可能版本不一樣，更不用說 Node 以及 NPM 所安裝的三方包，甚至本地預裝的開發者證書也時有不一致的狀況，因而整個團隊陷在了打包/包正確性/一致性/是否能打出來一堆問題造成的泥坑裏，艱難的對外解釋，艱難的互相配合，針對這個問題，咱們思路是讓這一切能夠傻瓜一點自動化，讓團隊共用一個打包環境，以它打的包爲準，因而咱們啓動了大伯伯打包平臺，採購了一臺高配 Mac Mini 部署在內網，把全部的配置項都經過界面來管理，簡要流程以下：

界面一開始很樸素，長這個樣子：

這個系統上線 1 年來，咱們已經打了 1000 多個包，由於打包而出現環境錯誤問題 0 次，極大的解放了團隊效率和提高打包的正確性，更重要的是對於團隊也沉澱了一些基於 Node 使用的技能，堅決了你們使用它的信心：

小菜前端第三次嚐鮮 NodeJS - 報表快速製做平臺

不管是 toB 仍是 toC 公司，把數據庫裏的數據拎出來，不管直接導出爲 Excel，仍是經過接口輸出到前端頁面中展現，都是硬剛需，小菜也不例外，並且小菜的業務早些年變化特別高頻，每次變化都要提一堆報表需求來監控調整先後的業務變化是否符合預期，若是沒有了報表就跟算命同樣全靠猜，而後這樣一個普通不能再普通的需求，卻讓小菜整個產品技術團隊頭疼了好幾年。

在緊張的業務開發項目中，讓先後端各自抽出資源來對接一個個的報表字段，再經過接口 - 頁面的聯調和發佈，是一件很是浪費資源的事情，後端感受本身像是一個寫 SQL 的和接口膠水代碼的，前端感受本身就是個純粹 Table 報表頁面仔，並且常常資源交叉衝突致使報表優先級下降甚至拖好久不能給到業務方，因此公司作了整整 3 年，總共才產出了 50 多個報表零散的扔在 ERP 系統裏面，針對這個問題，前端啓動了一個項目 - 大表哥報表平臺，用來解決報表產出效率的問題，實現 SQL 到頁面的自動生成，後端工程師，甚至會 SQL 的產品經理和運營均可以到平臺上，按照約定的規則粘貼一些 SQL，或者基於編輯頁面組裝一些 SQL 的子語句，咔咔！報表生成，這個系統上線 1 年來，生產力一會兒獲得釋放，總共產出了 400 多張報表：

公司的員工瀏覽報表天天都有一兩千次，直接導出 Excel 就導出了 1 萬 6 千屢次，已是公司內部最成功的一個工具產品，服務於全公司全部部門，報表展現大概長這樣：

一個報表的製做界面大概長這樣：

經過對 SQL 的各類查詢詞的組件封裝，能夠從界面快速生成一個可在數據庫執行的複雜 SQL 語句，或者反向貼入符合規則的 SQL，自動拆解成報表的表頭（字段的中文名稱），自動映射到組件（日期、排序、篩選、二級跳轉的子報表等等），包括整個報表的需求提出、描述、認領、上下線、製做和發佈這樣的工做流等等也所有用 NodeJS 實現，此次嚐鮮不只奠基了 NodeJS 在前端團隊絕對的位置，也實質性的在支撐業務這裏拿到很好的結果，更讓咱們感到欣喜的是，在報表系統裏面使用 GraphQL 是多麼的便捷，同時前端部門獨立支撐數據相關的業務產品這條路變得可行，NodeJS 的角色從工具也延展到了業務。

小菜前端第四次嚐鮮 NodeJS - 先後端數據聚合服務

若是說前面幾個，都是與服務端團隊解耦的，是前端能夠獨立完成的，那麼這一次，則是跟服務端在職能上和系統上都有強耦合的地方，是跨團隊研發層面的嘗試，此次發生在 2018 年 2 月份，也就是在前兩次嚐鮮後，咱們又一次比較大膽的突破。

背景依然是前端的頁面與後端的接口這裏，關於這個後面會專門有一篇詳細與你們聊聊先後端合做研發上咱們的思考，這裏我簡述一下，先後端的合做方式一般是數據接口，也就是數據格式和字段約定，一個吐數據一個消費數據，吐什麼樣的數據取決於消費什麼樣的數據，消費的數據則來源於產品流程上的 UI 展現形式，一份概念裏統一的數據，是有可能被分拆成兩個 UI 塊展現和複用，可能會讓接口顆粒度更小拆成 2 個，或者共用一個大的，頻次高一些的 UI 改版也會致使接口的通用性變得很弱，最終產生一堆大而全的重體積接口，進而對前端維護頁面和用戶的加載產生較大的影響。

並且接口裏面永遠是黑盒，在前端是看不全接口的能力了，一旦文檔沒有跟上，接口的輸出與 UI 的使用便會脫節，爲產品運行的帶來了更強的不穩定性，因此咱們會但願接口都是純粹的，用到多少字段就輸出多少字段，用到什麼格式就輸出什麼格式，同一個頁面的數據，儘可能一個接口返回而不是三四個接口返回，但這顯然對服務端提出了更高的要求，也是不少公司從前端產品層面試圖推進後端團隊時候無功而返的最大阻力。一我的羣中，大部分人都傾向於不做出改變，在沒有看到太多對本身帶來的好處以前，而短時間成本與長期紅利之間大部分會選擇短時間，由於它容易預見。

咱們的解決辦法是，用 NodeJS(EggJS) + GraphQL 搭建一個系統，它負責三件事：

• 負責對前端輸出所需數據（單接口，要什麼給什麼，無冗餘可組合）
• 負責去拿全部的服務端微服務接口數據（HTTP 協議或者 RPC 協議）
• 提供一個能夠在線鏈接接口、約束字段以及實時 Mock 的編輯系統

對它的要求是可在線編輯，可聯調測試，可數據熱發佈與熱回滾，這個系統上線後，咱們接管了 2 款 App 的接口需求，前端拼裝頁面和組合數據時候變得更靈活自如，同時正向逆向的數據監控，讓咱們對數據更有把控力，對於服務端來講，也能夠更加不關注 UI 如何，更關注業務領域的搭建與標準數據接口的封裝，它的界面長這個樣子：

還有接口地圖、數據關係網絡、接口字段監控、Mock 系統等等再也不一一截圖，這個 NodeJS 搭建的系統的複雜度仍是蠻高的，上線後咱們專門組織了一場技術分享 - 杭州第一屆 GraphQLParty，讓它開源的羣衆呼聲很高，咱們以爲還須要更多 NodeJS 的專家進來把系統進一步完善後，才真正能達到開源的標準，目前依然是在公司內部使用。

綜上，小菜前端基於 NodeJS 既有 Eat Your Own Shit 的內部場景的問題解決，也有直接服務於前端產品的工具，也有直接把數據當作業務來支撐公司決策的業務產品，還有專一在先後端研發效率的數據聚合層的全方位嘗試，從內到外從前到後，而這些系統的嘗試，又爲前端團隊沉澱了很是多的服務端能力，系統設計能力，甚至帶來跨語言棧的變化，童鞋們的技術能力也都大幅提高，因此 NodeJS 愈來愈成爲前端團隊的核心技術棧，目前第五次大規模的 NodeJS 使用咱們聚焦的是運維健康體系的搭建，相信在你的團隊，基於它作深度使用，只要能貼合你團隊的痛點，公司業務的痛點，解決掉問題帶來價值，那麼這些嘗試或者說試錯都是值得確定和鼓勵的。

最最後，本文做爲預熱篇，旨在針對以下話題爲你們輸出：

• 把團隊蠻荒到自動化運維的從 0 到 1
• 成長曆程總結輸出給社區，幫助更多的小團隊少走彎路
• 以一種可被量化的方式匯聚小菜前端的困惑、沉澱與方法路徑，給團隊帶來更多創做成就感
• 從更多視角側切進入團隊管理/技術演進/我的成長的過程當中，探討工程師團隊的價值最大化

若是你們感興趣，咱們小菜前端團隊，會集體智慧共同凝聚，一塊兒撰寫並推出一本偏前端職業生涯、技術成長和團隊成長的小冊，回饋給你們，你們在文後記得留言評論和提需求哦，還有別忘了加 Scott 微信哈： codingdream。