Nest.js 入手以及企业化的思考

本人是一名 Node.js 实习生，在进入大搜车以后，有幸见识到 Akyuu.js 这个框架。可是这个框架是使用 Express + Callback 的方式，我不是很喜欢。在个人推荐以及社区的发展下，组长决定用 TS + Async/Await 来试一试。因而我也去了解了一下 TS 的后端框架有哪些，结果通过别人推荐，找到了 Nest.js 这个想法几乎和我如出一辙的框架。

框架简介

由于我这个不是教程向，因此就不细讲，能够查看 Nest.js 官网。从个人感性角度来说，简单说一下如下几个特色：

• 去中心化路由。全部的路由经过装饰器与 Controller 绑定。简单、明了，学习成本低。
• TypeScript/Rx.js 加持。智能补全，代码分析，静态类型等等优势。若是你只是我的用用的话，可能会以为很全。可是放在企业当中使用，是很是大的优势。
• 依赖注入。从 Angular 那里学习而来，可是进行了一些简化，可是彻底够用。好比说简化掉了 deps。
• 模块思想。Node 社区的后端框架，其实都被 Express 导向到了中间件的模式。而 Nest.js 却从 Angular 当中吸收到了模块的思想。不一样的 Service、Controller、Component 组成不一样的模块。模块之间能够相互依赖，也能够独立存在，这大大减小了测试和逻辑的复杂度。
• 易于扩展。以往的框架，你能作的就是编写业务逻辑，而其余的你都很难去作到。因而传统的后端框架不得不引入了一套插件机制来加强框架的扩展性。可是 Nest.js 将插件的功能直接内置到了框架当中。传统的插件在这里能够认为就是一个模块，经过加载不一样的模块来添加不一样的功能。
• Express 基石。有人会说，不是如今 Koa 才是更好的模型么？洋葱模型能够解决更多复杂的问题。没错，我不反对这个言论。可是我想说的是，Express 仍是最简单最通用的方式，由于他不赖 Generator/Promise，只须要你又一个 Node.js 运行环境，支持 Callback 就能够了。（话说应该没有不支持 Callback 的 Node.js 环境吧，哈哈哈）无论怎么样，Express 的覆盖面仍是比 Koa 要广很多。
• 条条大路通罗马。那么有人就问了，那我要实现洋葱模型怎么办呢？我想说，办法老是会有的。而在 Nest.js 当中，经过 Interceptor ，能够很好的实现洋葱模型。也就是说你能够经过 Interceptor 来记录请求的耗时。
• 同步代码。这里所说的同步代码并非单单指的是 async/await。在不少支持 async/await 的框架中，若是你想返回值，若是是 Express ，你仍是须要调用 resp.send(await getValue())，而 koa 也是须要调用 ctx.body = await getValue()。可是在 Nest.js 中，只须要 return await getValue() 便可。实现真正的同步编写业务逻辑代码。
• 逻辑分层。其实不少功能，都是能够经过中间件来实现的。可是不一样类型的功能有不一样的需求，若是只是经过中间件来实现，势必会致使有一些重复的代码。因而 Nest.js 里面引入了 Pipe/Interceptor/Guard/ExceptionFilter 等逻辑层。不一样的层里面处理类似的事情，好比说 Pipe 处理的是输入数据的转换。而 Interceptor 来实现洋葱模型。Guard 用于权限校验等拦截任务。ExceptionFilter 用来处理错误数据。这种分层带来的好处就是可让代码更加清晰，主须要思考这个层须要作的事情，而不须要站在中间件的层面去考虑这个事情。
• Validation。自带校验，并且和 TS 结合的很是完美，使用起来很舒服，请看教程
• 输入参数的转换。这个实际上是一个很方便的方面。有的时候你须要将输入的参数转换成一个类，这个时候你就能够经过 Validation 进行转换。你要是不想用自动转换，能够经过传统的手动转换的方式。
• 测试功能完美。因为采用了依赖注入，因此测试简直简单的不得了。并且官方也提供了一系列测试工具，也能很好的解决单元测试的问题。

Nest.js 企业化当中的问题

• 目录无约束。在企业当中，不对目录进行约束会致使代码愈来愈乱。从而下降了代码可维护性。
• 没有配置管理功能。在框架开发中，配置每每是一个很重要的功能。好比说配置数据库的链接，配置监听的端口。
• 没有进程管理。虽然有提供 @nestjs/cli，可是这个提供的仅仅是一个项目的建立的能力。
• 部分文档讲解不详细，会提升入门的门槛。

不过总的来讲，前面几点也正是 Nest.js 灵活性的保证。可是咱们真正在开发当中，仍是须要一种合理的约束来保证开发的统一。

Nest.js 企业化的尝试

那么咱们这里针对上面的几个问题，尝试采用一些方式来进行约束。

目录结构

咱们对项目指定以下的规则：

• 所有经过 TypeScript 书写，而且所有位于 src 目录下
• 入口文件是 main.ts 若是没有特殊状况，不动这个文件
• 配置放在 src/config 文件夹下
• 全部的 Service/Controller/Logic/Component 等都挂载到 MainModule 下。
• 其中 module 文件夹存放自定义的 Module，或者说但愿独立成模块可是尚未彻底独立出来的。其中目录结构和这个项目目录结构相似
• boot 文件夹是项目启动代码的时候执行的，这部分在 Nest.js 当中没有给出。我这里打算添加这个功能，可是尚未想好具体的实现形式，因此待定。
• interface/enum 等数据随着对应的 service 导出。不另作说明。好比说 car.service.ts 除了能够导出 CarService 类之外，还能够导出 CarType enum。
• dest 文件夹是编译以后的文件，能够直接输入 node dest/main.js 运行。
• 命名规则
  • 全部的文件除了 main.ts 和类文件之外，都要添加类型后缀，好比说 user.model.ts car.controller.ts google.logic.ts。可是好比说只是一个 Car 类，那么能够直接命名成 car.ts
  • 不容许经过 export default 导出数据。一方面是为了方便导入的时候保证命名的统一，另外一方面能够随时导出 interface/enum 等内容。
  • 全部的测试文件后缀名都以 .spec.ts 或 .test.ts 结尾。

|-- 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 来提供配置的获取和查看。

在某些状况下，可能须要多级配置，模块级别的配置，应用级别的配置。那么 ConfigService 能够在获取配置的时候自动合并这些规则。

进程管理

如今已是 18 年了，不用 Docker 你真的对得起本身么？很明显是对不起的。因此进程管理这一块，咱们就交给 Docker 来处理。包括启动、中止、重启、日志等，都交给 Docker。

因而启动命令就能够简化成 node dest/main.js 便可。

那么你可能会想到，若是一个 Docker 环境给你分配了两个 u，那岂不是会浪费一个 u。理论上是的，那么你就能够经过 pm2 啊啥的本身去管理吧，哈哈哈，无论。

Iron.js

说了这么多，把上面的内容都沉淀下来，我得要给他取个名字，因而我就取成了 Iron。为啥叫 Iron 呢？由于 Iron Man。那为啥由于 Iron Man 呢？由于他制做的盔甲能够自由拆分，自动拼合。很是适合咱们这个项目的形态。

不过这个项目何时能沉淀下来，看我心情了。不过定个时间线吧，就在 4 月底，争取搞定。

由于这里面最大的问题就是配置的问题，须要深刻依赖注入，因此会麻烦一些。可是其余的方面更多的只是一种约束吧。

这就是我用 Nest.js 一周以来的心得。暂时就想到这么多，更多的内容等我后面再分析吧。

写完睡觉，答应女票了，啦啦啦~