文： 達孚

本文原創，轉載請註明作者及出處

首先上一下項目地址：

Nest：https://github.com/nestjs/nest

Nesk：https://github.com/kyoko-df/nesk

Nest初認識

Nest是一個深受angular激發的基於express的node框架，按照官網說明是一個旨在提供一個開箱即用的應用程序體系結構，允許輕鬆創建高度可測試，可擴展，鬆散耦合且易於維護的應用程序。

在設計層面雖然說是深受angular激發，但其實從後端開發角度來說類似於大家熟悉的Java Spring架構，使用了大量切面編程技巧，再通過裝飾器的結合完全了關註上的分離。同時使用了Typescript(也支持Javascript)為主要開發語言，更保證了整個後端系統的健壯性。

強大的Nest架構

那首先為什麼需要Nest框架，我們從去年開始大規模使用Node來替代原有的後端View層開發，給予了前端開發除了SPA以外的前後端分離方式。早期Node層的工作很簡單-渲染頁面代理介面，但在漸漸使用中大家會給Node層更多的寄託，尤其是一些內部項目中，你讓後端還要將一些現有的SOA介面進行包裝，對方往往是不願意的。那麼我們勢必要在Node層承接更多的業務，包括不限於對數據的組合包裝，對請求的許可權校驗，對請求數據的validate等等，早期我們的框架是最傳統的MVC架構，但是我們翻閱業務代碼，往往最後變成複雜且很難維護的Controller層代碼（從許可權校驗到頁面渲染一把擼到底:)）。

那麼我們現在看看Nest可以做什麼？從一個最簡單的官方例子開始看：

這裡就啟動了一個nest實例，先不看這個ValidationPipe，看ApplicationModule的內容：

這裡看到nest的第一層入口module，也就是模塊化開發的根本，所有的controller，component等等都可以根據業務切分到某個模塊，然後模塊之間還可以嵌套，成為一個完整的體系，借用張nest官方的圖：

在nest中的component概念其實一切可以注入的對象，對於依賴注入這個概念在此不做深入解釋，可以理解為開發者不需要實例化類，框架會進行實例化且保存為單例供使用。

Controller的代碼非常精簡，很多重複的工作都通過guards和interceptors解決，第一個裝飾器Controller可以接受一個字元串參數，即為路由參數，也就是這個Controller會負責/cats路由下的所有處理。首先RolesGuard會進行許可權校驗，這個校驗是自己實現的，大致結構如下：

context可以獲取controller的相關信息，再通過反射拿到handler上是否有定義roles的元信息，如果有就可以在邏輯里根據自己實現的auth方法或者用戶類型來決定是否讓用戶訪問相關handler。

interceptors即攔截器，它可以：

在方法執行之前/之後綁定額外的邏輯

轉換從函數返回的結果

轉換從函數拋出的異常

根據所選條件完全重寫函數 (例如, 緩存目的)

本示例有兩個攔截器一個用來記錄函數執行的時間，另一個對結果進行一層包裝，這兩個需求都是開發中很常見的需求，而且攔截器會提供一個rxjs的觀察者流來處理函數返回，支持非同步函數，我們可以通過map()來mutate這個流的結果，可以通過do運算符來觀察函數觀察序列的執行狀況，另外可以通過不返迴流的方式，從而阻止函數的執行，LoggingInterceptor例子如下：

回到最初的ValidationPipe，它是一個強大的校驗工具，我們看到前面的controller代碼中插入操作中有一個CreateCatDto，dto是一種數據傳輸對象，一個dto可以這樣定義：

然後ValidationPipe會檢查body是否符合這個dto，如果不符合就會就會執行你在pipe中設置的處理方案。具體是如何實現的可以再寫一篇文章了，所以我推薦你看nest中文指南(https://docs.nestjs.cn/)(順便感謝翻譯的同學們)

示例的完整代碼可以看01-cats-app（https://github.com/nestjs/nest/tree/master/examples/01-cats-app）

也就是說業務團隊中的熟練工或者架構師可以開發大量的模塊，中間件，異常過濾器，管道，看守器，攔截器等等，而不太熟練的開發者只需要完成controller的開發，在controller上像搭積木般使用這些設施，即完成了對業務的完整搭建。

Nesk-一個落地方案的嘗試

雖然我個人很喜歡Nest，但是我們公司已經有一套基於koa2的成熟框架Aconite，而Nest是基於express的，查看了下Nest的源碼，對express有一定的依賴，但是koa2和express在都支持async語法後，差異屬於可控範圍下。另外nest接受一個express的實例，在nesk中我們只需要調整為koa實例，那麼也可以是繼承於koa的任何項目實例，我們的框架在2.0版本也是一個在koa上繼承下來的node框架，基於此，我們只需要一個簡單的adapter層就可以無縫接入Aconite到nesk中，這樣減少了nesk和內部服務的捆綁，而將所有的公共內部服務整合保留在Aconite中。Nest對於我們來說只是一個更完美的開發範式，不承接任何公共模塊。

所以我們需要的工作可以簡單總結為：

支持Koa

適配Aconite

支持Koa我們在Nest的基礎上做了一些小改動完成了Nesk來兼容Koa體系。我們只需要完成Nesk和Aconite中間的Adapter層，就可以完成Nesk的落地，最後啟動處的代碼變成：

最後Nest有很多@nest scope下的包，方便一些工具接入nest，如果他們與express沒有關係，我們其實是可以直接使用的。但是包內部往往依賴@nest/common或者@nesk/core，這裡可以使用module-alias，進行一個重指向（你可以嘗試下graphql的例子）:

Nesk的地址Nesk（https://github.com/kyoko-df/nesk），我們對Nesk做了基本流程測試目前覆蓋了common和core，其它的在等待改進，歡迎一切願意一起改動的開發者。

不足與期待

其實從一個更好的方面來說，我們應當允許nest接受不同的底層框架，即既可以使用express，也可以使用koa，通過一個adapter層抹平差異。不過這一塊的改造成本會大一些。

另一方面nest有一些本身的不足，在依賴注入上，還是選擇了ReflectiveInjector，而Angular已經開始使用了StaticInjector，理論上StaticInjector減少了對Map層級的查找，有更好的性能，這也是我們決定分叉出一個nesk的原因，可以做一些更大膽的內部代碼修改。另外angular的依賴注入更強大，有例如useFactory和deps等方便測試替換的功能，是需要nest補充的.

最後所有的基於Koa的框架都會問到一個問題，能不能兼容eggjs(:))，其實無論是Nest還是Nesk都是一個強制開發規範的框架，只要eggjs還建立在koa的基礎上，就可以完成集成，只是eggjs在啟動層面的改動較大，而且開發範式和nest差異比較多，兩者的融合併沒有顯著的優勢。

總之Node作為一個比較靈活的後端開發方式，每個人心中都有自己覺得合適的開發範式，如果你喜歡這種方式，不妨嘗試下Nest或者Nesk。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！