一直以來(lái)我就很想找一個(gè)前端的微服務(wù)框架，就像Spring一樣那么好用，于是我找到了NestJs?。。。。?！

image.png

• 去中心化路由。所有的路由通過(guò)裝飾器與 Controller 綁定。簡(jiǎn)單、明了，學(xué)習(xí)成本低。
• TypeScript/Rx.js 加持。智能補(bǔ)全，代碼分析，靜態(tài)類型等等優(yōu)點(diǎn)。如果你只是個(gè)人用用的話，可能會(huì)覺(jué)得很全。但是放在企業(yè)當(dāng)中使用，是非常大的優(yōu)點(diǎn)。
• 依賴注入。從 Angular 那里學(xué)習(xí)而來(lái)，但是進(jìn)行了一些簡(jiǎn)化，但是完全夠用。比如說(shuō)簡(jiǎn)化掉了 deps。
• 模塊思想。Node 社區(qū)的后端框架，其實(shí)都被 Express 導(dǎo)向到了中間件的模式。而 Nest.js 卻從 Angular 當(dāng)中吸取到了模塊的思想。不同的 Service、Controller、Component 組成不同的模塊。模塊之間可以相互依賴，也可以獨(dú)立存在，這大大減少了測(cè)試和邏輯的復(fù)雜度。
• 易于擴(kuò)展。以往的框架，你能做的就是編寫業(yè)務(wù)邏輯，而其他的你都很難去做到。于是傳統(tǒng)的后端框架不得不引入了一套插件機(jī)制來(lái)增強(qiáng)框架的擴(kuò)展性。但是 Nest.js 將插件的功能直接內(nèi)置到了框架當(dāng)中。傳統(tǒng)的插件在這里可以認(rèn)為就是一個(gè)模塊，通過(guò)加載不同的模塊來(lái)添加不同的功能。
• Express 基石。有人會(huì)說(shuō)，不是現(xiàn)在 Koa 才是更好的模型么？洋蔥模型可以解決更多復(fù)雜的問(wèn)題。沒(méi)錯(cuò)，我不反對(duì)這個(gè)言論。但是我想說(shuō)的是，Express 還是最簡(jiǎn)單最通用的方式，因?yàn)樗毁?Generator/Promise，只需要你又一個(gè) Node.js 運(yùn)行環(huán)境，支持 Callback 就可以了。（話說(shuō)應(yīng)該沒(méi)有不支持 Callback 的 Node.js 環(huán)境吧，哈哈哈）不管怎么樣，Express 的覆蓋面還是比 Koa 要廣不少。
• 條條大路通羅馬。那么有人就問(wèn)了，那我要實(shí)現(xiàn)洋蔥模型怎么辦呢？我想說(shuō)，辦法總是會(huì)有的。而在 Nest.js 當(dāng)中，通過(guò) Interceptor ，可以很好的實(shí)現(xiàn)洋蔥模型。也就是說(shuō)你可以通過(guò) Interceptor 來(lái)記錄請(qǐng)求的耗時(shí)。
• 同步代碼。這里所說(shuō)的同步代碼并不是單單指的是 async/await。在很多支持 async/await 的框架中，如果你想返回值，如果是 Express ，你還是需要調(diào)用 resp.send(await getValue())，而 koa 也是需要調(diào)用 ctx.body = await getValue()。但是在 Nest.js 中，只需要 return await getValue() 即可。實(shí)現(xiàn)真正的同步編寫業(yè)務(wù)邏輯代碼。
• 邏輯分層。其實(shí)很多功能，都是可以通過(guò)中間件來(lái)實(shí)現(xiàn)的。但是不同類型的功能有不同的需求，如果只是通過(guò)中間件來(lái)實(shí)現(xiàn)，勢(shì)必會(huì)導(dǎo)致有一些重復(fù)的代碼。于是 Nest.js 里面引入了 Pipe/Interceptor/Guard/ExceptionFilter 等邏輯層。不同的層里面處理相似的事情，比如說(shuō) Pipe 處理的是輸入數(shù)據(jù)的轉(zhuǎn)換。而 Interceptor 來(lái)實(shí)現(xiàn)洋蔥模型。Guard 用于權(quán)限校驗(yàn)等攔截任務(wù)。ExceptionFilter 用來(lái)處理錯(cuò)誤數(shù)據(jù)。這種分層帶來(lái)的好處就是可以讓代碼更加清晰，主需要思考這個(gè)層需要做的事情，而不需要站在中間件的層面去考慮這個(gè)事情。
• Validation。自帶校驗(yàn)，而且和 TS 結(jié)合的非常完美，使用起來(lái)很舒服，請(qǐng)看教程
• 輸入?yún)?shù)的轉(zhuǎn)換。這個(gè)其實(shí)是一個(gè)很方便的方面。有的時(shí)候你需要將輸入的參數(shù)轉(zhuǎn)換成一個(gè)類，這個(gè)時(shí)候你就可以通過(guò) Validation 進(jìn)行轉(zhuǎn)換。你要是不想用自動(dòng)轉(zhuǎn)換，可以通過(guò)傳統(tǒng)的手動(dòng)轉(zhuǎn)換的方式。
• 測(cè)試功能完美。由于采用了依賴注入，所以測(cè)試簡(jiǎn)直簡(jiǎn)單的不得了。而且官方也提供了一系列測(cè)試工具，也能很好的解決單元測(cè)試的問(wèn)題。

Nest.js 企業(yè)化當(dāng)中的問(wèn)題

• 目錄無(wú)約束。在企業(yè)當(dāng)中，不對(duì)目錄進(jìn)行約束會(huì)導(dǎo)致代碼越來(lái)越亂。從而降低了代碼可維護(hù)性。
• 沒(méi)有配置管理功能。在框架開(kāi)發(fā)中，配置往往是一個(gè)很重要的功能。比如說(shuō)配置數(shù)據(jù)庫(kù)的連接，配置監(jiān)聽(tīng)的端口。
• 沒(méi)有進(jìn)程管理。雖然有提供 @nestjs/cli，但是這個(gè)提供的僅僅是一個(gè)項(xiàng)目的創(chuàng)建的能力。
• 部分文檔講解不詳細(xì)，會(huì)提高入門的門檻。

不過(guò)總的來(lái)說(shuō)，前面幾點(diǎn)也正是 Nest.js 靈活性的保證。但是我們真正在開(kāi)發(fā)當(dāng)中，還是需要一種合理的約束來(lái)保證開(kāi)發(fā)的統(tǒng)一。

Nest.js 企業(yè)化的嘗試

那么我們這里針對(duì)上面的幾個(gè)問(wèn)題，嘗試采用一些方式來(lái)進(jìn)行約束。

目錄結(jié)構(gòu)

我們對(duì)項(xiàng)目指定如下的規(guī)則：

• 全部通過(guò) TypeScript 書寫，并且全部位于 src 目錄下
• 入口文件是 main.ts 如果沒(méi)有特殊情況，不動(dòng)這個(gè)文件
• 配置放在 src/config 文件夾下
• 所有的 Service/Controller/Logic/Component 等都掛載到 MainModule 下。
• 其中 module 文件夾存放自定義的 Module，或者說(shuō)希望獨(dú)立成模塊但是還沒(méi)有完全獨(dú)立出來(lái)的。其中目錄結(jié)構(gòu)和這個(gè)項(xiàng)目目錄結(jié)構(gòu)類似
• boot 文件夾是項(xiàng)目啟動(dòng)代碼的時(shí)候執(zhí)行的，這部分在 Nest.js 當(dāng)中沒(méi)有給出。我這里打算添加這個(gè)功能，但是還沒(méi)有想好具體的實(shí)現(xiàn)形式，所以待定。
• interface/enum 等數(shù)據(jù)隨著對(duì)應(yīng)的 service 導(dǎo)出。不另做說(shuō)明。比如說(shuō) car.service.ts 除了可以導(dǎo)出 CarService 類以外，還可以導(dǎo)出 CarType enum。
• dest 文件夾是編譯之后的文件，可以直接輸入 node dest/main.js 運(yùn)行。
• 命名規(guī)則
  • 所有的文件除了 main.ts 和類文件以外，都要添加類型后綴，比如說(shuō) user.model.ts car.controller.ts google.logic.ts。但是比如說(shuō)只是一個(gè) Car 類，那么可以直接命名成 car.ts
  • 不允許通過(guò) export default 導(dǎo)出數(shù)據(jù)。一方面是為了方便導(dǎo)入的時(shí)候保證命名的統(tǒng)一，另一方面可以隨時(shí)導(dǎo)出 interface/enum 等內(nèi)容。
  • 所有的測(cè)試文件后綴名都以 .spec.ts 或 .test.ts 結(jié)尾。

|-- dest
    |--- ...
|-- src
    |-- config
    |-- controller
    |-- model
    |-- service
    |-- logic
    |-- component
    |-- boot
    |-- module
        |-- module-name
            |-- config
            |-- index.ts
            |-- module-name.module.ts
    |-- main.ts
    |-- main.module.ts

配置管理

我目前初步的想法是通過(guò)提供一個(gè) ConfigModule 暴露出一個(gè) ConfigService 來(lái)提供配置的獲取和查看。

在某些情況下，可能需要多級(jí)配置，模塊級(jí)別的配置，應(yīng)用級(jí)別的配置。那么 ConfigService 可以在獲取配置的時(shí)候自動(dòng)合并這些規(guī)則。

進(jìn)程管理

現(xiàn)在已經(jīng)是 19 年了，不用 Docker 你真的對(duì)得起自己么？很明顯是對(duì)不起的。所以進(jìn)程管理這一塊，我們就交給 Docker 來(lái)處理。包括啟動(dòng)、停止、重啟、日志等，都交給 Docker。

于是啟動(dòng)命令就可以簡(jiǎn)化成 node dest/main.js 即可。