Nest.js 入手以及企業(yè)化的思考

一直以來我就很想找一個前端的微服務(wù)框架，就像Spring一樣那么好用如贷，于是我找到了NestJsＯ莼ⅰ５教ぁ！Ｉ性场Ｎ迅濉！

image.png

去中心化路由谊路。所有的路由通過裝飾器與 Controller 綁定讹躯。簡單、明了缠劝，學(xué)習(xí)成本低潮梯。
TypeScript/Rx.js 加持。智能補全惨恭，代碼分析秉馏，靜態(tài)類型等等優(yōu)點。如果你只是個人用用的話脱羡，可能會覺得很全萝究。但是放在企業(yè)當(dāng)中使用，是非常大的優(yōu)點锉罐。
依賴注入帆竹。從 Angular 那里學(xué)習(xí)而來，但是進(jìn)行了一些簡化脓规，但是完全夠用判哥。比如說簡化掉了 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)的插件在這里可以認(rèn)為就是一個模塊获黔，通過加載不同的模塊來添加不同的功能蚀苛。
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 進(jìn)行轉(zhuǎn)換播掷。你要是不想用自動轉(zhuǎn)換审编，可以通過傳統(tǒng)的手動轉(zhuǎn)換的方式。
測試功能完美歧匈。由于采用了依賴注入垒酬，所以測試簡直簡單的不得了。而且官方也提供了一系列測試工具件炉，也能很好的解決單元測試的問題勘究。

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

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

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

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

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

目錄結(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ī)則胯究。

進(jìn)程管理

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

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