?Web 開發(fā)一直是 Node.js 的主流方向，無論新人必學(xué)的 Express / Koa，或者是社區(qū)流行的企業(yè)級框架 Egg / Nest，各類 Web 框架層出不窮。本次分享來自阿里巴巴前端技術(shù)專家劉子?。ǚ币祝┰诘谑鶎肈2前端技術(shù)論壇的分享，為大家?guī)?Node.js Web 框架的發(fā)展歷程，分析各類框架的適用場景及利弊，并基于阿里的 Node.js 框架 Midway，為大家介紹在過去這兩年，我們對下一代 Node.js Web 框架的思考、設(shè)計、實踐，包含如何面向前端做一款前端“愛用”的 Node.js 框架，如何面向未來標(biāo)準(zhǔn)甚至參與標(biāo)準(zhǔn)來設(shè)計 Node.js Web 框架兩部分。

Node.js & Web 框架簡述

Node.js是基于Chrome V8 JavaScript 引擎的運行時，一般用于編寫CLI、處理數(shù)據(jù)、編寫Restful API、進(jìn)行頁面渲染等等多種作用。之前JavaScript在瀏覽器端限制比較多，但是自從有了Node.js以后，應(yīng)用范圍得到很大拓展。

Web框架功能

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

Node.js框架的發(fā)展階段

Node.js的發(fā)展分成三個階段，分別是起步期、企業(yè)架構(gòu)期、面向前端期。

• 起步階段，主打輕量

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

其優(yōu)點是簡單易學(xué)，易于集成，Express框架容易集成到Nest和Webpack框架中，Koa.js框架容易集成到Egg和Midway框架中，生態(tài)繁榮，久經(jīng)考驗。

其缺陷也是比較明顯，表現(xiàn)為缺乏規(guī)范和最佳實踐、不利于團隊協(xié)作和大規(guī)模開發(fā)、Express年久失修。

• 企業(yè)階段，主打架構(gòu)

在2014年到2017年，Node.js規(guī)?；涞?，專業(yè)的Node.js工程師出現(xiàn)，主打企業(yè)級框架和架構(gòu)以及規(guī)?；蛨F隊協(xié)作化。

在這一段時間主要出現(xiàn)的框架有nest、Egg、Midway框架，但大多以Express和Koa框架作為基礎(chǔ)框架，如下圖：

企業(yè)級框架優(yōu)點為大而全，功能完善，規(guī)范并且最佳實踐明確，易于團隊協(xié)作，同時社區(qū)生態(tài)活躍。

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

• 面向前端

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

這些框架的優(yōu)點主要是來自于前端，全棧開發(fā)，簡單容易學(xué)習(xí)，支持Serverless部署。

其缺陷是后端功能較弱，自定義擴展困難，強依賴于平臺支持。

下面是兩個Demo示例：

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

在2020年的時候，一份stateofjs 2020關(guān)于Node.js Web框架滿意度對比的調(diào)查報告表明，Next.js成功登頂，并且Express.js框架仍然受到關(guān)注。

Node.js Web 框架滿意度調(diào)研（stateofjs 2020）

總結(jié)

1. Node.js Web框架迭代與前端行業(yè)發(fā)展密切相關(guān)；
2. 前端應(yīng)用場景多于純Node.js后端場景；
3. 面向前端設(shè)計的全?？蚣芘d起，使得Node.js用法回歸簡潔和輕量。

Midway - 面向前端的框架演進(jìn)之路

Midway是2014年開發(fā)的框架，發(fā)布了7個大版本，2018年正式開源。

Midway作為一款企業(yè)級開發(fā)框架，技術(shù)選型上，主要有TypeScript（靜態(tài)類型、多人協(xié)作）、IoC（復(fù)雜架構(gòu)、面向接口編程）、Egg（統(tǒng)一框架、復(fù)用生態(tài)）。Midway Demo示例如下圖：

Node.js應(yīng)用狀況

集團在2019年的時候，Node.js應(yīng)用狀況表現(xiàn)為：

1. 服務(wù)器利用率低：集團1600+Node.js應(yīng)用，常年cpu利用率<10%，乃至5%，服務(wù)器利用率低。
2. DevOps成本高：前端維護乏力，由于是Docker應(yīng)用、限流、日志、跨語言，所以導(dǎo)致Devops成本過高。

傳統(tǒng)應(yīng)用的缺點限制了Node.js在阿里的進(jìn)一步發(fā)展。

前端訴求

1. 后端往大后臺下沉，前端往小前臺發(fā)力，提升生產(chǎn)力。
2. 前端同學(xué)希望將中臺服務(wù)快速組合為各類業(yè)務(wù)接口，和端側(cè)同步快速交付前臺，以更快的響應(yīng)業(yè)務(wù)需求變化來幫助業(yè)務(wù)試錯。

總體上需要賦能前端，讓云原生給前端降本增效。

技術(shù)方向

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

面臨挑戰(zhàn)

• 用戶群體割裂，如何在一個框架下服務(wù)好兩種用戶？

前端工程師和Node.js工程師出現(xiàn)割裂。前端工程師偶爾寫接口，希望簡單易上手；對于Node.js工程師來說，因為日常管理上萬行代碼，更注重于復(fù)雜場景的應(yīng)對能力。

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

簡單場景和企業(yè)級場景不同，簡單場景要求快速實現(xiàn)CRUD，接口聚合；企業(yè)級場景注重維護性，依賴注入，基礎(chǔ)架構(gòu)，簡單場景將會逐步演化成為復(fù)雜場景。

• 前端范式變更

目前主流的前端都在從Class Component 向 Function + Hooks轉(zhuǎn)變，包括React、Vue等，最終會導(dǎo)致函數(shù)式開發(fā)和OOP開發(fā)并存，如下圖比較圖：

同一個開發(fā)者在寫前、后端的時候，思維是不一樣的，那么框架有沒有可能支持函數(shù)式開發(fā)，又能與OOP 并存？

解決辦法：漸進(jìn)式設(shè)計

通過Midway的漸進(jìn)式設(shè)計來解決，我們把Midway架構(gòu)進(jìn)行分層，從下到上主要為Midway核心、編碼范式、生態(tài)、場景化、和Modern Web。對于前端來說的解決方案就是Hooks。

• Hooks

函數(shù)即接口

JavaScript 函數(shù)即接口，統(tǒng)一并且無協(xié)議。

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

獲取請求上下文

針對前后端范式不一致的問題，設(shè)置了useContext API，可以直接拿到運行時的參數(shù)，最終實現(xiàn)無需手動傳入?yún)?shù)，就能夠?qū)崿F(xiàn)前端保持一致。示例代碼如下：

獲取URL查詢參數(shù)

自定義Hooks

面向全棧應(yīng)用設(shè)計

典型工程代碼目錄

上圖是典型工程代碼目錄，包括服務(wù)端目錄、接口目錄、頁面資源、應(yīng)用入口等，都在src下面，最終實現(xiàn)統(tǒng)一管理和配置，共享src代碼、類型。

簡化接口調(diào)用

“零”API調(diào)用

和傳統(tǒng)接口調(diào)用不同，在一體化應(yīng)用中，只需要導(dǎo)入函數(shù)，調(diào)用函數(shù)并使用返回值，因為都在一個src目錄，且都是TypeScript，這種直接導(dǎo)入的方式是可行的，同時后端的返回值也不需要生成或推斷，最終實現(xiàn)“零”API調(diào)用，節(jié)約時間，節(jié)省文檔，實現(xiàn)直接調(diào)用。

• 漸進(jìn)式-類似于搭積木一樣進(jìn)行演化

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

如果是面向后端，可以使用IoC+裝飾器、Middleware、ORM、Swagger、Cache、HTTP、gRPC，部署在Server上，實現(xiàn)復(fù)雜的企業(yè)級應(yīng)用。

也可以面向隨著時間流逝復(fù)雜度增加的應(yīng)用，如下圖：

落地情況

Hooks于2020年4月發(fā)布，有2500多個應(yīng)用，是阿里前端的主流模式。

總結(jié)

1. 企業(yè)內(nèi)仍存在簡單場景與復(fù)雜場景，框架設(shè)計應(yīng)考慮到此問題；
2. Node.js Web 框架應(yīng)關(guān)注開發(fā)者體驗，面向前端工程師設(shè)計；
3. 云 + 端的研發(fā)模式將成為未來的主流研發(fā)模式。

未來 - 面向標(biāo)準(zhǔn)&規(guī)劃

類型安全

例如社區(qū)的Prisma框架，可以生成ORM，ORM可以根據(jù)數(shù)據(jù)庫實時生成。如果前端也是自動生成，那么將會實現(xiàn)前端到后端再到數(shù)據(jù)庫全鏈路的類型安全，如果后端修改了，那么前端也將會自動報錯。

展望：云端融合

目前有兩個在推的提案，分別為JS Module Blocks（動態(tài)引入代碼）和JS Module Fragments（模塊可以命名，模塊可以靜態(tài)導(dǎo)入）。

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

方向示例

目前正在與前端委員會標(biāo)準(zhǔn)化小組推進(jìn)TC39 提案，反饋場景，謀求推進(jìn)至Stage 2。

項目網(wǎng)址：https://github.com/tc39/proposal-module-fragments/issues/14?