Node-js Web 框架再進化 - 面向前端與未來標準

Web 開發一直是 Node.js 的主流方向，無論新人必學的 Express / Koa，或者是社區流行的企業級框架 Egg / Nest，各類 Web 框架層出不窮。本次分享來自阿里巴巴前端技術專家劉子健（繁易）在第十六屆 D2 前端技術論壇的分享，爲大家帶來 Node.js Web 框架的發展歷程，分析各類框架的適用場景及利弊，並基於阿里的 Node.js 框架 Midway，爲大家介紹在過去這兩年，我們對下一代 Node.js Web 框架的思考、設計、實踐，包含如何面向前端做一款前端 “愛用” 的 Node.js 框架，如何面向未來標準甚至參與標準來設計 Node.js Web 框架兩部分。

Node.js & Web 框架簡述

Node.js 是基於 Chrome V8 JavaScript 引擎的運行時，一般用於編寫 CLI、處理數據、編寫 Restful API、進行頁面渲染等等多種作用。之前 JavaScript 在瀏覽器端限制比較多，但是自從有了 Node.js 以後，應用範圍得到很大拓展。

1、Web 框架功能

現代的 Web 開發不管使用什麼語言都離不開 Web 框架。Web 框架具有 Restful API、數據庫 CRUD、頁面渲染、身份校驗等功能，提供了高效開發 Web 應用的方式，同時 Web 框架存在適用場景以及規則約束，有源源不斷的框架推陳出新。

2、Node.js 框架的發展階段

Node.js 的發展分成三個階段，分別是起步期、企業架構期、面向前端期。

a、起步階段，主打輕量
2009 年 Node.js 出現，2010 年 Express 框架出現，2013 年出現 Koa 框架。當時前端工程師主要是在嚐鮮，不敢在業務上做太多的嘗試和落地，更多的是驗證 Node.js Web 場景可行性。在起步期階段，框架主打輕量和極簡。下面是兩個框架的寫法示例。

其優點是簡單易學，易於集成，Express 框架容易集成到 Nest 和 Webpack 框架中，Koa.js 框架容易集成到 Egg 和 Midway 框架中，生態繁榮，久經考驗。

其缺陷也是比較明顯，表現爲缺乏規範和最佳實踐、不利於團隊協作和大規模開發、Express 年久失修。

b、企業階段，主打架構

在 2014 年到 2017 年，Node.js 規模化落地，專業的 Node.js 工程師出現，主打企業級框架和架構以及規模化和團隊協作化。

在這一段時間主要出現的框架有 nest、Egg、Midway 框架，但大多以 Express 和 Koa 框架作爲基礎框架，如下圖：

企業級框架優點爲大而全，功能完善，規範並且最佳實踐明確，易於團隊協作，同時社區生態活躍。

缺陷是大而全導致上手成本高；限制多，難擴展。

c、面向前端
從 2016 之後，Node.js 發展成熟完善，Node 4.0 發佈，前端工程師人數急速增加，主打面向前端框架的設計，以及簡潔和輕量，在這個階段中主要框架是 Next.js 以及 Nuxt.js 框架。

這些框架的優點主要是來自於前端，全棧開發，簡單容易學習，支持 Serverless 部署。

其缺陷是後端功能較弱，自定義擴展困難，強依賴於平臺支持。
下面是兩個 Demo 示例：

上面是 Next.js，下面是 Nuxt.js

在 2020 年的時候，一份 stateofjs 2020 關於 Node.js Web 框架滿意度對比的調查報告表明，Next.js 成功登頂，並且 Express.js 框架仍然受到關注。

Node.js Web 框架滿意度調研（stateofjs 2020）

3、總結

1. Node.js Web 框架迭代與前端行業發展密切相關；

2. 前端應用場景多於純 Node.js 後端場景；

3. 面向前端設計的全棧框架興起，使得 Node.js 用法迴歸簡潔和輕量。

Midway - 面向前端的框架演進之路

Midway 是 2014 年開發的框架，發佈了 7 個大版本，2018 年正式開源。

Midway 作爲一款企業級開發框架，技術選型上，主要有 TypeScript（靜態類型、多人協作）、IoC（複雜架構、面向接口編程）、Egg（統一框架、複用生態）。Midway Demo 示例如下圖：

1、Node.js 應用狀況

集團在 2019 年的時候，Node.js 應用狀況表現爲：

a、服務器利用率低： 集團 1600+Node.js 應用，常年 cpu 利用率 < 10%，乃至 5%，服務器利用率低。

b、DevOps 成本高： 前端維護乏力，由於是 Docker 應用、限流、日誌、跨語言，所以導致 Devops 成本過高。
傳統應用的缺點限制了 Node.js 在阿里的進一步發展。

2、前端訴求

a、 後端往大後臺下沉，前端往小前臺發力，提升生產力。

b、 前端同學希望將中臺服務快速組合爲各類業務接口，和端側同步快速交付前臺，以更快的響應業務需求變化來幫助業務試錯。
總體上需要賦能前端，讓雲原生給前端降本增效。

3、技術方向

通過以上現狀和訴求，2019-2020 阿里巴巴前端委員會的四大技術方向爲：
a、搭建服務；b、Serverless；c、智能化；d、IDE。

4、面臨挑戰

a、用戶羣體割裂，如何在一個框架下服務好兩種用戶？

前端工程師和 Node.js 工程師出現割裂。前端工程師偶爾寫接口，希望簡單易上手；對於 Node.js 工程師來說，因爲日常管理上萬行代碼，更注重於複雜場景的應對能力。

b、使用場景不同，如何在一個框架下支持兩種場景？

簡單場景和企業級場景不同，簡單場景要求快速實現 CRUD，接口聚合；企業級場景注重維護性，依賴注入，基礎架構，簡單場景將會逐步演化成爲複雜場景。

c、前端範式變更

目前主流的前端都在從 Class Component 向 Function + Hooks 轉變，包括 React、Vue 等，最終會導致函數式開發和 OOP 開發並存，如下圖比較圖：

同一個開發者在寫前、後端的時候，思維是不一樣的，那麼框架有沒有可能支持函數式開發，又能與 OOP 並存？

5、解決辦法：漸進式設計

通過 Midway 的漸進式設計來解決，我們把 Midway 架構進行分層，從下到上主要爲 Midway 核心、編碼範式、生態、場景化、和 Modern Web。對於前端來說的解決方案就是 Hooks。

a、Hooks

• 函數即接口

JavaScript 函數即接口，統一併且無協議。

函數名稱生成路徑，可以根據參數的長度決定請求類型，通過 TyperScript 可以推斷返回類型。通過這種方式，基於函數元信息生成接口。

• 獲取請求上下文

針對前後端範式不一致的問題，設置了 useContext API，可以直接拿到運行時的參數，最終實現無需手動傳入參數，就能夠實現前端保持一致。示例代碼如下：

獲取 URL 查詢參數

自定義 Hooks

• 面向全棧應用設計

典型工程代碼目錄

上圖是典型工程代碼目錄，包括服務端目錄、接口目錄、頁面資源、應用入口等，都在 src 下面，最終實現統一管理和配置，共享 src 代碼、類型。

• 簡化接口調用

“零”API 調用

和傳統接口調用不同，在一體化應用中，只需要導入函數，調用函數並使用返回值，因爲都在一個 src 目錄，且都是 TypeScript，這種直接導入的方式是可行的，同時後端的返回值也不需要生成或推斷，最終實現 “零”API 調用，節約時間，節省文檔，實現直接調用。

b、漸進式 - 類似於搭積木一樣進行演化

把 Midway 支持的功能按照項目類型、開發方式、拓展組件、觸發器、部署平臺進行羅列，可以像像搭積木一樣，選擇相應的積木就可以實現。比如面向前端一體化應用，可以選擇一體化項目、函數式、Config、HTTP、FaaS，如下圖：

如果是面向後端，可以使用 IoC + 裝飾器、Middleware、ORM、Swagger、Cache、HTTP、gRPC，部署在 Server 上，實現複雜的企業級應用。

也可以面向隨着時間流逝複雜度增加的應用，如下圖：

6、落地情況

Hooks 於 2020 年 4 月發佈，有 2500 多個應用，是阿里前端的主流模式。

7、總結

a、企業內仍存在簡單場景與複雜場景，框架設計應考慮到此問題；
b、Node.js Web 框架應關注開發者體驗，面向前端工程師設計；
c、雲 + 端的研發模式將成爲未來的主流研發模式。

未來 - 面向標準 & 規劃

1、類型安全

例如社區的 Prisma 框架，可以生成 ORM，ORM 可以根據數據庫實時生成。如果前端也是自動生成，那麼將會實現前端到後端再到數據庫全鏈路的類型安全，如果後端修改了，那麼前端也將會自動報錯。

2、展望：雲端融合

目前有兩個在推的提案，分別爲 JS Module Blocks（動態引入代碼）和 JS Module Fragments（模塊可以命名，模塊可以靜態導入）。

根據這兩個提案，引入我們的第三個方向，最終實現在一個文件中，可以實現 server 端和 ssr 端以及 client 端融合。

目前正在與前端委員會標準化小組推進 TC39 提案，反饋場景，謀求推進至 Stage 2。

項目網址：https://github.com/tc39/proposal-module-fragments/issues/14

https://developer.aliyun.com/ebook/7492

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/hfhs9TsJluxMIwbCEg9N4w