最近在重構一個內部使用的配置平臺，主要重構平臺的後端部分，目標是使用nest框架替換原有的koa框架。跌跌撞撞了幾天，把專案慢慢的重構好了，在重構的過程中慢慢體會到nest框架的優勢。

本文將會介紹nest框架，以及為什麼我們選擇使用這個框架（關於遷移過程遇到的問題可以關注後續的文章）。

進入正題，為什麼要使用nest來重構原有的node專案呢？

Nest的專案結構清晰明瞭

如果大家沒接觸過nest，可以結合nest官網以及fast-nest 一個基於nest的快速啟動專案來構建一個初印象。

如圖，這是官網示例專案的目錄結構，可以發現它和我們傳統的node專案有些不同，在目錄結構我們就能看到模組化影子。先是主入口main.ts，後是主模組app.module.ts，最後是掛載在app中的cat模組。

這與我們之前接觸的大部分專案都不太一樣，我們之前接觸到的node專案，有些是將controller層彙集到一個router檔案中處理，有些是分開了多個路由檔案最後再彙總。再說說service層，在我接觸過的node專案中，有些是沒有將service層分離出來的，在controller層就把所有的事情完成並返回。

與之相比，nest的專案結構就比較有意思了。cat模組是個獨立的目錄，與app.module同級，在這個目錄中包含了與cat相關的controller、service甚至是介面約定，最後暴露出cat.module.ts，注入到app中，完成掛載。在這種風格的目錄結構中，我們可以清晰的看出整個專案的脈絡，無論是初識專案或是專案迭代，都可能很容易的找到切入點。

從關注點分離的角度來說，我們以往的node專案結構大都是根據技術點來分離我們的關注，與controller相關的放一塊，與service相關的放一塊，介面約定放一塊等等。而nest專案則是從業務層面進行分離，服務於同一個業務的內容構成一個模組放到同一個目錄中。要說這兩種分離方案哪個更好，倒是比較難說，它們各有優劣，但是我們一般的服務都是為各種業務提供支援的，為何不考慮專注於業務呢:)

Nest對Typescript支援完備

Nest自身就是通過typescript開發的，所以我們初始化完一個nest專案後可以直接使用ts來進行後續的開發，不需要再做額外的js轉ts操作。

由於Nest天生支援typescript這一特性，使得它對

也許大家會疑惑，用裝飾器就用唄，有啥好特地拿出來說？

這就要結合Nest自帶的註解式開發說起：

如圖，我們可以通過裝飾器來完成對請求引數的獲取，例如我們想獲取請求頭中的某一項，我們可以這麼寫

@Controller('/test')
export class TestController {

    @Post('/create')
    async createUser(
        @Headers('name') name: string,@Body('id') id: string
    ) {
        // ...
    }
    
}
複製程式碼

在上述controller中，我們為 /test/create 路由下的方法獲取了請求頭中 name 的值，以及請求body中 id 的值，相較於未使用裝飾器的寫法有以下幾點小優勢。

• 程式碼量明顯減少，利於程式碼整潔
• service所需引數一目瞭然，如果只是想知道某個service需要什麼引數，我們只需要在對應的controller中就能讀到
• 自定義裝飾器，用於獲取自己拓展的請求引數

開源表現及專案相容程度

進到Nest的github中不難發現，專案的commit提交數以及issue解決數都十分優秀。我們使用某個開源專案除了專案本身的穩定，一般也很注意這個專案的活躍程度，而活躍程度的評判標準我覺得commit以及issue都可以當做衡量的標準。

看到這，也許有些同學會問了，如果有一個現成的express專案，可以直接把Nest套上去嗎？

答案是肯定的。Nest本身應該屬於更上一層的抽象框架，在專案底層當然是可以使用express的，並且Nest還提供了配套的適配包 @nestjs/platform-express ，安裝依賴後在初始化時將express物件傳入Nest的啟動器中，就可以使用express進行業務開發了。

尾聲

關於Nest的初探到此已經將近完結，對筆者而言這個框架給我帶來的更多是一種規整感。它賦予專案極其解耦且靈活的模組化能力，並不需要我們額外去規劃一套約定，只要使用了它，我們的專案自然而然會變成模組化的專案。相信隨著後續的使用，可以總結更多關於Nest的使用乾貨分享給大家。