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

image.png

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

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

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

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

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

那么我們這里針對上面的幾個問題，嘗試采用一些方式來進行約束。

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

我們對項目指定如下的規(guī)則：

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

配置管理

我目前初步的想法是通過提供一個 ConfigModule 暴露出一個 ConfigService 來提供配置的獲取和查看。

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

進程管理

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

于是啟動命令就可以簡化成 node dest/main.js 即可。