秘籍

REPL

REPL 是一个简单的交互式环境，它接受单个用户输入，执行这些输入，并将结果返回给用户。REPL 功能允许您直接从终端检查依赖关系图并调用提供程序（和控制器）上的方法。

用法

若要在 REPL 模式下运行 NestJS 应用程序，请创建一个新 repl.ts 文件 (与现有的 main.ts 文件放在一起) ，并在其中添加以下代码：

@@filename(repl)
import { repl } from '@nestjs/core';
import { AppModule } from './app.module';
async function bootstrap() {
  await repl(AppModule);
}
bootstrap();
@@switch
import { repl } from '@nestjs/core';
import { AppModule } from './app.module';
async function bootstrap() {
  await repl(AppModule);
}
bootstrap();

现在可以在终端中，使用以下命令启动 REPL：

$ npm run start -- --entryFile repl

info 提示 repl 返回 Node.js REPL server 对象.

启动并运行后，您应该会在控制台中看到以下消息：

LOG [NestFactory] Starting Nest application...
LOG [InstanceLoader] AppModule dependencies initialized
LOG REPL initialized

现在你可以开始与依赖图交互了。例如，您可以检索 AppService (我们在这里使用 starter 项目作为示例)并调用 getHello() 方法:

> get(AppService).getHello()
'Hello World!'

您可以从终端中执行任何 JavaScript 代码，例如，将 AppController 的 实例分配给局部变量，并使用 await 调用异步方法：

> appController = get(AppController)
AppController { appService: AppService {} }
> await appController.getHello()
'Hello World!'

要显示给定 provider 或 controller 中可用的所有公共方法，请使用 methods() 函数，如下所示:

> methods(AppController)
Methods:
 ◻ getHello

To print all registered modules as a list together with their controllers and providers, use debug(). 要将所有注册的模块以及它们的控制器和提供者打印为一个列表，请使用 debug()。

> debug()
AppModule:
 - controllers:
  ◻ AppController
 - providers:
  ◻ AppService

快速演示：

您可以在下面的小节中找到有关现有的、预定义的本机方法的更多信息。

原生函数

内置的 NestJS REPL 提供了一些全局可用的原生函数。你可以调用 help() 来列出它们。

If you don’t recall what’s the signature (ie: expected parameters and a return type) of a function, you can call <function_name>.help. For instance:

如果你不记得函数的签名是什么(即:预期参数和返回类型)，你可以调用 <function_name>.help。 例如

> $.help
Retrieves an instance of either injectable or controller, otherwise, throws exception.
Interface: $(token: InjectionToken) => any

info 提示 这些函数接口使用TypeScript函数类型表达式语法编写。

监视模式

在开发过程中，可以在监视模式下运行REPL，以自动反映所有代码更改:

$ npm run start -- --watch --entryFile repl

这有一个缺陷，REPL的命令历史记录在每次重新加载后都会被丢弃，这可能很麻烦。 幸运的是，有一个非常简单的解决方案。像这样修改你的 bootstrap 函数:

async function bootstrap() {
  const replServer = await repl(AppModule);
  replServer.setupHistory(".nestjs_repl_history", (err) => {
    if (err) {
      console.error(err);
    }
  });
}

现在，在运行/重新加载之间保存历史记录。

CRUD生成器

在一个项目的生命周期中，当我们新增特性的时候，我们通常需要在应用中添加新的资源。这些资源通常需要我们在每次新增资源的时候进行一些重复操作。

介绍

想象一下真实世界中的场景，我们需要通过两个CRUD的终端暴露User和Product两个实体。参考最佳实践，我们为每个实体进行以下操作。

• 生成一个模块 (nest g mo) 来组织代码，使其保持清晰的界限（将相关模块分组）
• 生成一个控制器 (nest g co) 来定义CRUD路径（或者GraphQL应用的查询和变更）
• 生成一个服务 (nest g s) 来表示/隔离业务逻辑
• 生成一个实体类/接口来代表资源数据类型
• 生成数据转换对象（或者GraphQL应用输入）来决定数据如何通过网络传输

很多步骤！

为了加速执行重复步骤，Nest CLI提供了一个生成器（schematic(原理)）可以自动生成所有的模板文件以减少上述步骤，同时让开发者感觉更易用。

该schematic支持生成HTTP控制器，微服务控制器，GraphQL处理器（代码优先或者原理优先），以及WebSocket网关等。

生成新资源

在项目根目录下执行以下代码来生成资源。

$ nest g resource

nest g resource命令不仅仅生成所有Nestjs构件模块(模块，服务，控制器类)也生成实体类，DTO类和测试(.spec)文件。

如下是一个生成的控制器 (REST API):

@Controller('users')
export class UsersController {
  constructor(private readonly usersService: UsersService) {}
  @Post()
  create(@Body() createUserDto: CreateUserDto) {
    return this.usersService.create(createUserDto);
  }
  @Get()
  findAll() {
    return this.usersService.findAll();
  }
  @Get(':id')
  findOne(@Param('id') id: string) {
    return this.usersService.findOne(+id);
  }
  @Put(':id')
  update(@Param('id') id: string, @Body() updateUserDto: UpdateUserDto) {
    return this.usersService.update(+id, updateUserDto);
  }
  @Delete(':id')
  remove(@Param('id') id: string) {
    return this.usersService.remove(+id);
  }
}

它也自动生成了所有CRUD终端占位符（REST API路径，GraphQL查询和编译，微服务和WebSocket网关的消息订阅器）—一键所有内容。

!> 生成的资源类未与任何特定ORM（或者数据源）绑定，以在任何项目下通用。默认地，所有方法都包含了占位符，允许你用特定项目的数据源填充。类似地，如果你需要生成GraphQL应用的处理器，只要在传输层选择GraphQL（代码优先）或者GraphQL(原理优先)即可。

这里生成一个处理器类而不是一个REST API控制器：

$ nest g resource users
> ? What transport layer do you use? GraphQL (code first)
> ? Would you like to generate CRUD entry points? Yes
> CREATE src/users/users.module.ts (224 bytes)
> CREATE src/users/users.resolver.spec.ts (525 bytes)
> CREATE src/users/users.resolver.ts (1109 bytes)
> CREATE src/users/users.service.spec.ts (453 bytes)
> CREATE src/users/users.service.ts (625 bytes)
> CREATE src/users/dto/create-user.input.ts (195 bytes)
> CREATE src/users/dto/update-user.input.ts (281 bytes)
> CREATE src/users/entities/user.entity.ts (187 bytes)
> UPDATE src/app.module.ts (312 bytes)

?> 像这样传递--no-spec参数nest g resource users --no-spec来避免生成测试文件。

在下面我们可以看到，不仅生成了所有变更和查询的样板文件，也把他们绑定到了一起，我们可以使用UsersService, User Entity, 和DTO。

import { Resolver, Query, Mutation, Args, Int } from '@nestjs/graphql';
import { UsersService } from './users.service';
import { User } from './entities/user.entity';
import { CreateUserInput } from './dto/create-user.input';
import { UpdateUserInput } from './dto/update-user.input';
@Resolver(() => User)
export class UsersResolver {
  constructor(private readonly usersService: UsersService) {}
  @Mutation(() => User)
  createUser(@Args('createUserInput') createUserInput: CreateUserInput) {
    return this.usersService.create(createUserInput);
  }
  @Query(() => [User], { name: 'users' })
  findAll() {
    return this.usersService.findAll();
  }
  @Query(() => User, { name: 'user' })
  findOne(@Args('id', { type: () => Int }) id: number) {
    return this.usersService.findOne(id);
  }
  @Mutation(() => User)
  updateUser(@Args('updateUserInput') updateUserInput: UpdateUserInput) {
    return this.usersService.update(updateUserInput.id, updateUserInput);
  }
  @Mutation(() => User)
  removeUser(@Args('id', { type: () => Int }) id: number) {
    return this.usersService.remove(id);
  }
}

SWC (快速编译器)

（待翻译）

Passport (认证)

Passport 是最流行的 node.js 认证库，为社区所熟知，并成功地应用于许多生产应用中。使用 @nestjs/passport 模块，可以很容易地将这个库与 Nest 应用集成。从高层次来看，Passport 执行一系列步骤以：

• 通过验证用户的”凭证”(例如用户名/密码、JSON Web令牌( JWT )或身份提供者的身份令牌)来验证用户的身份。

• 管理经过身份验证的状态(通过发出可移植的令牌，例如 JWT，或创建一个 Express 会话)

• 将有关经过身份验证的用户的信息附加到请求对象，以便在路由处理程序中进一步使用

Passport具有丰富的策略生态系统，可实施各种身份验证机制。 尽管概念上很简单，但是您可以选择的 Passport 策略集非常多，并且有很多种类。 Passport 将这些不同的步骤抽象为标准模式，而 @nestjs/passport 模块将该模式包装并标准化为熟悉的 Nest 构造。

在本章中，我们将使用这些强大而灵活的模块为 RESTful API服务器实现完整的端到端身份验证解决方案。您可以使用这里描述的概念来实现 Passport 策略，以定制您的身份验证方案。您可以按照本章中的步骤来构建这个完整的示例。

认证要求

让我们充实一下我们的需求。对于此用例，客户端将首先使用用户名和密码进行身份验证。一旦通过身份验证，服务器将发出 JWT，该 JWT 可以在后续请求的授权头中作为 token发送，以验证身份验证。我们还将创建一个受保护的路由，该路由仅对包含有效 JWT 的请求可访问。

我们将从第一个需求开始:验证用户。然后我们将通过发行 JWT 来扩展它。最后，我们将创建一个受保护的路由，用于检查请求上的有效 JWT 。

首先，我们需要安装所需的软件包。Passport 提供了一种名为 Passport-local 的策略，它实现了一种用户名/密码身份验证机制，这符合我们在这一部分用例中的需求。

$ npm install --save @nestjs/passport passport passport-local
$ npm install --save-dev @types/passport-local

?> 对于您选择的 任何 Passport 策略，都需要 @nestjs/Passport 和 Passport 包。然后，需要安装特定策略的包(例如，passport-jwt 或 passport-local)，它实现您正在构建的特定身份验证策略。此外，您还可以安装任何 Passport策略的类型定义，如上面的 @types/passport-local 所示，它在编写 TypeScript 代码时提供了帮助。

实现 Passport 策略

现在可以实现身份认证功能了。我们将首先概述用于 任何 Passport 策略的流程。将 Passport 本身看作一个框架是有帮助的。框架的优雅之处在于，它将身份验证过程抽象为几个基本步骤，您可以根据实现的策略对这些步骤进行自定义。它类似于一个框架，因为您可以通过提供定制参数(作为 JSON 对象)和回调函数( Passport 在适当的时候调用这些回调函数)的形式来配置它。 @nestjs/passport 模块将该框架包装在一个 Nest 风格的包中，使其易于集成到 Nest 应用程序中。下面我们将使用 @nestjs/passport ，但首先让我们考虑一下 vanilla Passport 是如何工作的。

在 vanilla Passport 中，您可以通过提供以下两项配置策略:

1. 特定于该策略的选项。例如，在 JWT 策略中，您可以提供一个秘令来对令牌进行签名。

2. “验证回调”，在这里您可以告诉 Passport 如何与您的用户存储交互(在这里您可以管理用户帐户)。在这里，验证用户是否存在(或创建一个新用户)，以及他们的凭据是否有效。Passport 库期望这个回调在验证成功时返回完整的用户消息，在验证失败时返回 null(失败定义为用户没有找到，或者在使用 Passport-local 的情况下，密码不匹配)。

使用 @nestjs/passport ，您可以通过扩展 PassportStrategy 类来配置 passport 策略。通过调用子类中的 super() 方法传递策略选项(上面第 1 项)，可以选择传递一个 options 对象。通过在子类中实现 validate() 方法，可以提供verify 回调(上面第 2 项)。

我们将从生成一个 AuthModule 开始，其中有一个 AuthService :

$ nest g module auth
$ nest g service auth

当我们实现 AuthService 时，我们会发现在 UsersService 中封装用户操作是很有用的，所以现在让我们生成这个模块和服务:

$ nest g module users
$ nest g service users

替换这些生成文件的默认内容，如下所示。对于我们的示例应用程序，UsersService 只是在内存中维护一个硬编码的用户列表，以及一个根据用户名检索用户列表的 find 方法。在真正的应用程序中，这是您使用选择的库(例如 TypeORM、Sequelize、Mongoose等)构建用户模型和持久层。

users/users.service.ts

import { Injectable } from '@nestjs/common';
// 这应该是代表一个用户实体的真正的类/接口
export type User = any;
@Injectable()
export class UsersService {
  private readonly users: User[];
  constructor() {
    this.users = [
      {
        userId: 1,
        username: 'john',
        password: 'changeme',
      },
      {
        userId: 2,
        username: 'chris',
        password: 'secret',
      },
      {
        userId: 3,
        username: 'maria',
        password: 'guess',
      },
    ];
  }
  async findOne(username: string): Promise<User | undefined> {
    return this.users.find((user) => user.username === username);
  }
}

在 UsersModule 中，唯一需要做的更改是将 UsersService 添加到 @Module 装饰器的 exports 数组中，以便提供给其他模块外部可见(我们很快将在 AuthService 中使用它)。

users/users.module.ts

import { Module } from '@nestjs/common';
import { UsersService } from './users.service';
@Module({
  providers: [UsersService],
  exports: [UsersService],
})
export class UsersModule {}

我们的 AuthService 的任务是检索用户并验证密码。为此，我们创建了 validateUser() 方法。在下面的代码中，我们使用 ES6 扩展操作符从 user 对象中提取 password 属性，然后再返回它。稍后，我们将从 Passport 本地策略中调用 validateUser() 方法。

auth/auth.service.ts

import { Injectable } from '@nestjs/common';
import { UsersService } from '../users/users.service';
@Injectable()
export class AuthService {
  constructor(private readonly usersService: UsersService) {}
  async validateUser(username: string, pass: string): Promise<any> {
    const user = await this.usersService.findOne(username);
    if (user && user.password === pass) {
      const { password, ...result } = user;
      return result;
    }
    return null;
  }
}

?> 当然，在实际的应用程序中，您不会以纯文本形式存储密码。 取而代之的是使用带有加密单向哈希算法的 bcrypt 之类的库。使用这种方法，您只需存储散列密码，然后将存储的密码与输入密码的散列版本进行比较，这样就不会以纯文本的形式存储或暴露用户密码。为了保持我们的示例应用程序的简单性，我们违反了这个绝对命令并使用纯文本。不要在真正的应用程序中这样做!

现在，我们更新 AuthModule 来导入 UsersModule 。

auth/auth.module.ts

import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { UsersModule } from '../users/users.module';
@Module({
  imports: [UsersModule],
  providers: [AuthService],
})
export class AuthModule {}

实现 Passport local

现在我们可以实现 Passport 本地身份验证策略。在 auth 文件夹中创建一个名为 local.strategy.ts 文件，并添加以下代码:

auth/local.strategy.ts

import { Strategy } from 'passport-local';
import { PassportStrategy } from '@nestjs/passport';
import { Injectable, UnauthorizedException } from '@nestjs/common';
import { AuthService } from './auth.service';
@Injectable()
export class LocalStrategy extends PassportStrategy(Strategy) {
  constructor(private readonly authService: AuthService) {
    super();
  }
  async validate(username: string, password: string): Promise<any> {
    const user = await this.authService.validateUser(username, password);
    if (!user) {
      throw new UnauthorizedException();
    }
    return user;
  }
}

我们遵循了前面描述的所有 Passport 策略。在我们的 passport-local 用例中，没有配置选项，因此我们的构造函数只是调用 super() ，没有 options 对象。

?> 我们可以在调用 super() 时传递一个选项对象，以自定义 Passport 策略的行为。在本例中，passport-local 策略默认在请求体中使用名为 username 和 password 的属性。传递一个选项对象可指定不同的属性名称，例如 super({{ '{' }} usernameField: 'email' {{ '}' }}) 。 要了解更多信息，请查看 Passport 文档 。

我们还实现了 validate() 方法。对于每个策略，Passport 将使用适当的特定于策略的一组参数调用 verify 函数(使用 @nestjs/Passport 中的 validate() 方法实现)。对于本地策略，Passport 需要一个具有以下签名的 validate() 方法: validate(username: string, password: string): any。

大多数验证工作是在我们的 AuthService 中完成的(在 UserService 的帮助下)，所以这个方法非常简单。任何 Passport 策略的 validate() 方法都将遵循类似的模式，只是表示凭证的细节方面有所不同。如果找到了用户并且凭据有效，则返回该用户，以便 Passport 能够完成其任务(例如，在请求对象上创建user 属性)，并且请求处理管道可以继续。如果没有找到，我们抛出一个异常，让异常层处理它。

通常，每种策略的 validate() 方法的惟一显著差异是如何确定用户是否存在和是否有效。例如，在 JWT 策略中，根据需求，我们可以评估解码令牌中携带的 userId 是否与用户数据库中的记录匹配，或者是否与已撤销的令牌列表匹配。因此，这种子类化和实现特定于策略验证的模式是一致的、优雅的和可扩展的。

我们需要配置 AuthModule 来使用刚才定义的 Passport 特性。更新 auth.module。看起来像这样:

auth/auth.module.ts

import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { UsersModule } from '../users/users.module';
import { PassportModule } from '@nestjs/passport';
import { LocalStrategy } from './local.strategy';
@Module({
  imports: [UsersModule, PassportModule],
  providers: [AuthService, LocalStrategy],
})
export class AuthModule {}

内置 Passport 守卫

守卫章节描述了守卫的主要功能：确定请求是否由路由处理程序。这仍然是正确的，我们将很快使用这个标准功能。但是，在使用 @nestjs/passport 模块的情况下，我们还将引入一个新的小问题，这个问题一开始可能会让人感到困惑，现在让我们来讨论一下。从身份验证的角度来看，您的应用程序可以以两种状态存在:

1. 用户/客户端 未 登录(未通过身份验证)
2. 用户/客户端 已 登录(已通过身份验证)

在第一种情况下(用户没有登录)，我们需要执行两个不同的功能:

• 限制未经身份验证的用户可以访问的路由（即拒绝访问受限制的路由）。 我们将使用熟悉的警卫来处理这个功能，方法是在受保护的路由上放置一个警卫。我们将在这个守卫中检查是否存在有效的 JWT ，所以我们稍后将在成功发出 JWT 之后处理这个守卫。

• 当以前未经身份验证的用户尝试登录时，启动身份验证步骤。这时我们向有效用户发出 JWT 的步骤。考虑一下这个问题，我们知道需要 POST 用户名/密码凭证来启动身份验证，所以我们将设置 POST /auth/login 路径来处理这个问题。这就提出了一个问题:在这条路由上，我们究竟如何实施 Passport-local 战略?

答案很简单:使用另一种稍微不同类型的守卫。@nestjs/passport 模块为我们提供了一个内置的守卫，可以完成这一任务。这个保护调用 Passport 策略并启动上面描述的步骤(检索凭证、运行verify 函数、创建用户属性等)。

上面列举的第二种情况(登录用户)仅仅依赖于我们已经讨论过的标准类型的守卫，以便为登录用户启用对受保护路由的访问。

登录路由

有了这个策略，我们现在就可以实现一个简单的 /auth/login 路由，并应用内置的守卫来启动 Passport-local 流。 打开 app.controller.ts 文件，并将其内容替换为以下内容:

app.controller.ts

import { Controller, Request, Post, UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Controller()
export class AppController {
  @UseGuards(AuthGuard('local'))
  @Post('auth/login')
  async login(@Request() req) {
    return req.user;
  }
}

对于 @UseGuard(AuthGuard('local'))，我们使用的是一个 AuthGuard ，它是在我们扩展 Passport-local 策略时 @nestjs/passportautomatic 为我们准备的。我们来分析一下。我们的 Passport 本地策略默认名为"local" 。我们在 @UseGuards() 装饰器中引用这个名称，以便将它与 Passport-local 包提供的代码关联起来。这用于消除在应用程序中有多个 Passport 策略时调用哪个策略的歧义(每个策略可能提供一个特定于策略的 AuthGuard )。虽然到目前为止我们只有一个这样的策略，但我们很快就会添加第二个，所以这是消除歧义所需要的。

为了测试我们的路由，我们将 /auth/login 路由简单地返回用户。这还允许我们演示另一个 Passport 特性: Passport 根据从 validate() 方法返回的值自动创建一个 user 对象，并将其作为 req.user 分配给请求对象。稍后，我们将用创建并返回 JWT 的代码替换它。

因为这些是 API 路由，所以我们将使用常用的cURL库来测试它们。您可以使用 UsersService 中硬编码的任何用户对象进行测试。

$ # POST to /auth/login
$ curl -X POST http://localhost:3000/auth/login -d '{"username": "john", "password": "changeme"}' -H "Content-Type: application/json"
$ # result -> {"userId":1,"username":"john"}

如果上述内容可以正常工作，可以通过直接将策略名称传递给AuthGuard()来引入代码库中的魔术字符串。作为替代，我们推荐创建自己的类，如下所示：

auth/local-auth.guard.ts

import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Injectable()
export class LocalAuthGuard extends AuthGuard('local') {}

@UseGuards(LocalAuthGuard)
@Post('auth/login')
async login(@Request() req) {
  return req.user;
}

JWT 功能

我们已经准备好进入 JWT 部分的认证系统。让我们回顾并完善我们的需求:

• 允许用户使用用户名/密码进行身份验证，返回 JWT 以便在后续调用受保护的 API 端点时使用。我们正在努力满足这一要求。为了完成它，我们需要编写发出 JWT 的代码。

• 创建基于token 的有效JWT 的存在而受保护的 API 路由。

我们需要安装更多的包来支持我们的 JWT 需求:

$ npm install --save @nestjs/jwt passport-jwt
$ npm install @types/passport-jwt --save-dev

@nest/jwt 包是一个实用程序包，可以帮助 jwt 操作。passport-jwt 包是实现 JWT 策略的 Passport包，@types/passport-jwt 提供 TypeScript 类型定义。

让我们仔细看看如何处理 POST /auth/login 请求。我们使用 Passport-local 策略提供的内置AuthGuard 来装饰路由。这意味着:

1. 只有在用户验证通过之后 ，才会调用路由处理程序

2. req 参数将包含一个用户属性(在 passport-local 身份验证流期间由 Passport 填充)

考虑到这一点，我们现在终于可以生成一个真正的 JWT ，并以这种方式返回它。为了使我们的服务保持干净的模块化，我们将在 authService 中生成 JWT 。在 auth 文件夹中添加 auth.service.ts 文件，并添加 login() 方法，导入JwtService ，如下所示:

auth/auth.service.ts

import { Injectable } from '@nestjs/common';
import { UsersService } from '../users/users.service';
import { JwtService } from '@nestjs/jwt';
@Injectable()
export class AuthService {
  constructor(private readonly usersService: UsersService, private readonly jwtService: JwtService) {}
  async validateUser(username: string, pass: string): Promise<any> {
    const user = await this.usersService.findOne(username);
    if (user && user.password === pass) {
      const { password, ...result } = user;
      return result;
    }
    return null;
  }
  async login(user: any) {
    const payload = { username: user.username, sub: user.userId };
    return {
      access_token: this.jwtService.sign(payload),
    };
  }
}

我们使用 @nestjs/jwt 库，该库提供了一个 sign() 函数，用于从用户对象属性的子集生成 jwt，然后以简单对象的形式返回一个 access_token 属性。注意:我们选择 sub 的属性名来保持我们的 userId 值与JWT 标准一致。不要忘记将 JwtService 提供者注入到 AuthService中。

现在，我们需要更新 AuthModule 来导入新的依赖项并配置 JwtModule 。

首先，在 auth 文件夹下创建 auth/constants.ts，并添加以下代码:

auth/constants.ts

export const jwtConstants = {
  secret: 'secretKey',
};

我们将使用上方的对象来在 JWT 的生成和验证步骤之间共享密钥。

!> 不要公共地暴露这个密钥。 我们这里这样做是为了清楚地说明代码正在做什么，但在生产系统中，你必须要使用恰当的措施来 保护这个密钥 ，例如机密库 、环境变量、配置服务等。

现在，打开 auth 文件夹下的 auth.module.ts ，并将其更新为如下所示：

auth / auth.module.ts;
import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { LocalStrategy } from './local.strategy';
import { UsersModule } from '../users/users.module';
import { PassportModule } from '@nestjs/passport';
import { JwtModule } from '@nestjs/jwt';
import { jwtConstants } from './constants';
@Module({
  imports: [
    UsersModule,
    PassportModule,
    JwtModule.register({
      secret: jwtConstants.secret,
      signOptions: { expiresIn: '60s' },
    }),
  ],
  providers: [AuthService, LocalStrategy],
  exports: [AuthService],
})
export class AuthModule {}

我们使用 register() 来配置 JwtModule ，并传入一个配置对象。要了解更多 Nest JwtModule 的信息，请查看 这里 ；要了解可用配置项的详细信息，请查看 这里 。

现在我们可以更新 /auth/login 路径来返回 JWT 。

app.controller.ts

import { Controller, Request, Post, UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
import { AuthService } from './auth/auth.service';
@Controller()
export class AppController {
  constructor(private readonly authService: AuthService) {}
  @UseGuards(AuthGuard('local'))
  @Post('auth/login')
  async login(@Request() req) {
    return this.authService.login(req.user);
  }
}

让我们再次使用 cURL 来测试路由。您可以使用 UsersService 中硬编码的任何 user 对象进行测试。

$ # POST to /auth/login
$ curl -X POST http://localhost:3000/auth/login -d '{"username": "john", "password": "changeme"}' -H "Content-Type: application/json"
{"access_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."}
$ # 注意：上方的 JWT 省略了一部分

实现 Passport JWT

我们现在可以实现最后一个需求：通过要求请求中携带有效的 JWT 来保护接口。Passport 这里也能帮到我们。它提供了用于用 JSON Web 标记保护 RESTful 接口的 passport-jwt 策略。在 auth 文件夹中创建文件 jwt.strategy.ts，并添加以下代码:

auth/jwt.strategy.ts

import { ExtractJwt, Strategy } from 'passport-jwt';
import { PassportStrategy } from '@nestjs/passport';
import { Injectable } from '@nestjs/common';
import { jwtConstants } from './constants';
@Injectable()
export class JwtStrategy extends PassportStrategy(Strategy) {
  constructor() {
    super({
      jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
      ignoreExpiration: false,
      secretOrKey: jwtConstants.secret,
    });
  }
  async validate(payload: any) {
    return { userId: payload.sub, username: payload.username };
  }
}

对于我们的 JwtStrategy ，我们遵循了前面描述的所有 Passport 策略的相同配方。这个策略需要一些初始化，因此我们通过在 super() 调用中传递一个 options 对象来实现。您可以在这里阅读关于可用选项的更多信息。在我们的例子中，这些选项是:

• jwtFromRequest:提供从请求中提取 JWT 的方法。我们将使用在 API 请求的授权头中提供token的标准方法。这里描述了其他选项。

ignoreExpiration:为了明确起见，我们选择默认的 false 设置，它将确保 JWT 没有过期的责任委托给 Passport 模块。这意味着，如果我们的路由提供了一个过期的 JWT ，请求将被拒绝，并发送 401 Unauthorized 的响应。Passport 会自动为我们办理。

secretOrKey:我们使用权宜的选项来提供对称的秘密来签署令牌。其他选项，如 pemo 编码的公钥，可能更适合于生产应用程序(有关更多信息，请参见此处)。如前所述，无论如何， 不要把这个秘密公开 。

validate() 方法值得讨论一下。对于 JWT 策略，Passport 首先验证 JWT 的签名并解码 JSON。然后调用我们的 validate() 方法，该方法将解码后的 JSON 作为其单个参数传递。根据 JWT 签名的工作方式，我们可以保证接收到之前已签名并发给有效用户的有效 token 令牌。

因此，我们对 validate() 回调的响应很简单:我们只是返回一个包含 userId 和 username 属性的对象。再次回忆一下，Passport 将基于 validate() 方法的返回值构建一个user 对象，并将其作为属性附加到请求对象上。

同样值得指出的是，这种方法为我们留出了将其他业务逻辑注入流程的空间(就像”挂钩”一样)。例如，我们可以在 validate() 方法中执行数据库查询，以提取关于用户的更多信息，从而在请求中提供更丰富的用户对象。这也是我们决定进行进一步令牌验证的地方，例如在已撤销的令牌列表中查找 userId ，使我们能够执行令牌撤销。我们在示例代码中实现的模型是一个快速的 "无状态JWT" 模型，其中根据有效 JWT 的存在立即对每个 API 调用进行授权，并在请求管道中提供关于请求者(其 userid 和 username)的少量信息。

在 AuthModule 中添加新的 JwtStrategy 作为提供者:

auth/auth.module.ts

import { Module } from '@nestjs/common';
import { AuthService } from './auth.service';
import { LocalStrategy } from './local.strategy';
import { JwtStrategy } from './jwt.strategy';
import { UsersModule } from '../users/users.module';
import { PassportModule } from '@nestjs/passport';
import { JwtModule } from '@nestjs/jwt';
import { jwtConstants } from './constants';
@Module({
  imports: [
    UsersModule,
    PassportModule,
    JwtModule.register({
      secret: jwtConstants.secret,
      signOptions: { expiresIn: '60s' },
    }),
  ],
  providers: [AuthService, LocalStrategy, JwtStrategy],
  exports: [AuthService],
})
export class AuthModule {}

通过导入 JWT 签名时使用的相同密钥，我们可以确保 Passport 执行的验证阶段和 AuthService 执行的签名阶段使用一个公共密钥。

最后，我们定义 JwtAuthGuard 类，它扩展了内置的 AuthGuard :

auth/jwt-auth.guard

import { Injectable } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {}

实现受保护的路由和 JWT 策略守卫

我们现在可以实现受保护的路由及其相关的守卫。

打开 app.controller.ts 文件，更新如下:

app.controller.ts

import { Controller, Get, Request, Post, UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
import { AuthService } from './auth/auth.service';
@Controller()
export class AppController {
  constructor(private readonly authService: AuthService) {}
  @UseGuards(AuthGuard('local'))
  @Post('auth/login')
  async login(@Request() req) {
    return this.authService.login(req.user);
  }
  @UseGuards(AuthGuard('jwt'))
  @Get('profile')
  getProfile(@Request() req) {
    return req.user;
  }
}

同样，我们将应用 AuthGuard 守卫，在我们配置 passport-jwt 模块时 @nestjs/passport 模块自动为我们提供过它。这个守卫由它的默认名称 jwt 引用。当我们请求GET /profile 路由时，守卫程序将自动调用我们的 passport-jwt 自定义配置逻辑，验证 `J

确保应用程序正在运行，并使用 cURL 测试路由。

$ # GET /profile
$ curl http://localhost:3000/profile
$ # result -> {"statusCode":401,"error":"Unauthorized"}
$ # POST /auth/login
$ curl -X POST http://localhost:3000/auth/login -d '{"username": "john", "password": "changeme"}' -H "Content-Type: application/json"
$ # result -> {"access_token":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2Vybm... }
$ # GET /profile 使用上一步返回的 JWT 作为 bearer code
$ curl http://localhost:3000/profile -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2Vybm..."
$ # result -> {"userId":1,"username":"john"}

注意在 AuthModule 中，我们配置了 JWT 的过期时间是 60 秒 。这是一个很短的时间，而且处理 JWT 过期和刷新的细节超出了本文的讨论范围。然而，我们仍然选择了这样设置，以演示 JWT 的这个重要特性。如果您在尝试 GET /auth/profile 请求之前等待超过了 60 秒，您会收到 401 Unauthorized 的响应。这是因为 Passport 会自动检查 JWT 的过期时间，从而省去了在应用程序中这样做的麻烦。

我们现在已经完成了 JWT 认证的实现。JavaScript 客户端（例如 Angular/React/Vue）和其他 JavaScript 应用现在可以安全地使用我们的 API 服务器进行认证和通信。

扩展守卫

在大多数情况下，默认提供好的 AuthGuard 类已经足够用了。然而，在有些用例中，您会想要简单地扩展默认的错误处理或认证逻辑。为了实现它，您可以扩展内置的类并在子类中覆盖方法。

import {
  ExecutionContext,
  Injectable,
  UnauthorizedException,
} from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  canActivate(context: ExecutionContext) {
    // 在这里添加您自定义的认证逻辑
    // 例如，调用 super.logIn(request) 来建立一个 session
    return super.canActivate(context);
  }
  handleRequest(err, user, info) {
    // 您可以基于 "info" 或 "err" 参数抛一个错误
    if (err || !user) {
      throw err || new UnauthorizedException();
    }
    return user;
  }
}

除了扩展默认的错误处理或认证逻辑，我们可以通过一系列链式策略来进行身份验证。第一个成功、重定向或出错的策略将终止调用链。身份验证失败时，将依次通过每个策略，如果所有策略都失败，则最终失败。

export class JwtAuthGuard extends AuthGuard(['strategy_jwt_1', 'strategy_jwt_2', '...']) { ... }

启用全局身份验证

如果您的大部分接口默认都应该受到保护，您可以将认证守卫注册为 全局守卫 ，接着，您只需要标记哪些路由应为公共路由，而无需在每一个控制器的上方都使用 @UseGuards() 装饰器。

首先，在任意一个模块中，（例如在 AuthModule 中）使用下方的结构将 AuthGuard 注册为全局守卫。

providers: [
  {
    provide: APP_GUARD,
    useClass: JwtAuthGuard,
  },
],

有了这些，Nest 会自动将 JwtAuthGuard 绑定到所有接口上。

现在我们必须提供一个将路由声明为公共路由的机制。为了实现它，我们可以使用 SetMetadata 装饰器工厂函数，创建一个自定义装饰器。

import { SetMetadata } from '@nestjs/common';
export const IS_PUBLIC_KEY = 'isPublic';
export const Public = () => SetMetadata(IS_PUBLIC_KEY, true);

在上面的文件中，我们导出了两个常量。一个是名为 IS_PUBLIC_KEY 的元数据键；另一个是名为 Public 的新装饰器（您也可以把它命名为任何适用于您项目的名称，例如 SkipAuth 或 AllowAnon）。

现在我们有了自定义的 @Public() 装饰器，我们可以用它来装饰任意方法，如下所示：

@Public()
@Get()
findAll() {
  return [];
}

最后，当元数据 "isPublic" 被找到时，我们需要 JwtAuthGuard 返回 true 。为了实现它，我们将使用 Reflector 类（ 了解更多 ）。

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  constructor(private reflector: Reflector) {
    super();
  }
  canActivate(context: ExecutionContext) {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);
    if (isPublic) {
      return true;
    }
    return super.canActivate(context);
  }
}

请求范围策略

passport API 基于将策略注册到库的全局实例。因此策略并没有设计为依赖请求的选项的或者根据每个请求动态生成实例（更多内容见请求范围提供者）。当你配置你的策略为请求范围时，Nest永远不会将其实例化，因为它并没有和任何特定路径绑定。并没有一个物理方法来决定哪个”请求范围”策略会根据每个请求执行。

然而，在策略中总有办法动态处理请求范围提供者。我们在这里利用模块参考特性。

首先，打开local.strategy.ts文件并且将ModuleRef按照正常方法注入其中：

constructor(private moduleRef: ModuleRef){
  super({
    passReqToCallback:true;
  })
}

!> 注意： ModuleRef 类需要从@nestjs/core中导入。

要保证passReqToCallback属性和上述示例中一样配置为true。

在下一步中，请求的实例将被用于获取一个当前上下文标识，而不是生成一个新的（更多关于请求上下文的内容见这里)。

现在，在LocalStrategy类的validate()方法中，使用ContextIdFactory类中的getByRequest()方法来创建一个基于请求对象的上下文 id，并将其传递给resolve()调用：

async validate(
  request: Request,
  username: string,
  password: string,
) {
  const contextId = ContextIdFactory.getByRequest(request);
  // "AuthService" 是一个请求范围的提供者
  const authService = await this.moduleRef.resolve(AuthService, contextId);
  ...
}

在上述例子中，resolve()方法会异步返回AuthService提供者的请求范围实例（我们假设AuthService被标示为一个请求范围提供者）。

自定义 Passport

使用 register() 方法，任何标准的 Passport 自定义选项都能以相同的方式传递。可用的选项取决于实施的策略。例如：

PassportModule.register({ session: true });

您还可以在策略的构造函数中传递一个 options 对象来配置它们。至于本地策略，你可以通过例如:

constructor(private readonly authService: AuthService) {
  super({
    usernameField: 'email',
    passwordField: 'password',
  });
}

看看 Passport Website 官方文档吧。

命名策略

在实现策略时，可以通过向 PassportStrategy 函数传递第二个参数来为其提供名称。如果你不这样做，每个策略将有一个默认的名称(例如，”jwt”的 jwt策略 ):

export class JwtStrategy extends PassportStrategy(Strategy, 'myjwt')

然后，通过一个像 @AuthGuard('myjwt') 这样的装饰器来引用它。

GraphQL

为了使用带有 GraphQL 的 AuthGuard ，扩展内置的 AuthGuard 类并覆盖 getRequest() 方法。

@Injectable()
export class GqlAuthGuard extends AuthGuard('jwt') {
  getRequest(context: ExecutionContext) {
    const ctx = GqlExecutionContext.create(context);
    return ctx.getContext().req;
  }
}

要在 graphql 解析器中获得当前经过身份验证的用户，可以定义一个@CurrentUser()装饰器:

import { createParamDecorator, ExecutionContext } from '@nestjs/common';
import { GqlExecutionContext } from '@nestjs/graphql';
export const CurrentUser = createParamDecorator((data: unknown, context: ExecutionContext) => {
  const ctx = GqlExecutionContext.create(context);
  return ctx.getContext().req.user;
});

要在解析器中使用上述装饰器，请确保将其作为查询的参数:

@Query(returns => User)
@UseGuards(GqlAuthGuard)
whoAmI(@CurrentUser() user: User) {
  return this.userService.findById(user.id);
}

热重载

对应用程序的引导过程影响最大的是 TypeScript 编译。但问题是，每次发生变化时，我们是否必须重新编译整个项目？一点也不。这就是为什么 webpack HMR（Hot-Module Replacement）大大减少了实例化您的应用程序所需的时间。

?> 请注意，webpack这不会自动将（例如 graphql 文件）复制到 dist 文件夹中。类似地，webpack 与全局静态路径（例如中的 entities 属性 TypeOrmModule ）不兼容。

CLI

如果使用的是 Nest CLI，则配置过程非常简单。CLI 包装 webpack，允许使用 HotModuleReplacementPlugin。

安装

首先，我们安装所需的软件包：

$ npm i --save-dev webpack-node-externals run-script-webpack-plugin webpack

配置（Configuration）

然后，我们需要创建一个webpack-hmr.config.js，它是webpack的一个配置文件，并将其放入根目录。

const nodeExternals = require('webpack-node-externals');
const { RunScriptWebpackPlugin } = require('run-script-webpack-plugin');
module.exports = function (options, webpack) {
  return {
    ...options,
    entry: ['webpack/hot/poll?100', options.entry],
    externals: [
      nodeExternals({
        allowlist: ['webpack/hot/poll?100'],
      }),
    ],
    plugins: [
      ...options.plugins,
      new webpack.HotModuleReplacementPlugin(),
      new webpack.WatchIgnorePlugin({
        paths: [/\.js$/, /\.d\.ts$/],
      }),
      new RunScriptWebpackPlugin({ name: options.output.filename }),
    ],
  };
};

此函数获取包含默认 webpack 配置的原始对象，并返回一个已修改的对象和一个已应用的 HotModuleReplacementPlugin 插件。

热模块更换

为了启用 HMR，请打开应用程序入口文件（ main.ts ）并添加一些与 Webpack相关的说明，如下所示：

declare const module: any;
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
  if (module.hot) {
    module.hot.accept();
    module.hot.dispose(() => app.close());
  }
}
bootstrap();

就这样。为了简化执行过程，请将这两行添加到 package.json 文件的脚本中。

"start:dev": "nest build --webpack --webpackPath webpack-hmr.config.js --watch"

现在只需打开你的命令行并运行下面的命令：

$ npm run start:dev

没有使用 CLI

如果您没有使用 Nest CLI ，配置将稍微复杂一些(需要更多的手动步骤)。

安装

首先安装所需的软件包：

$ npm i --save-dev webpack webpack-cli webpack-node-externals ts-loader run-script-webpack-plugin

配置

然后，我们需要创建一个webpack.config.js，它是 webpack 的一个配置文件，并将其放入根目录。

const webpack = require('webpack');
const path = require('path');
const nodeExternals = require('webpack-node-externals');
const { RunScriptWebpackPlugin } = require('run-script-webpack-plugin');
module.exports = {
  entry: ['webpack/hot/poll?100', './src/main.ts'],
  target: 'node',
  externals: [
    nodeExternals({
      allowlist: ['webpack/hot/poll?100'],
    }),
  ],
  module: {
    rules: [
      {
        test: /.tsx?$/,
        use: 'ts-loader',
        exclude: /node_modules/,
      },
    ],
  },
  mode: 'development',
  resolve: {
    extensions: ['.tsx', '.ts', '.js'],
  },
  plugins: [
    new webpack.HotModuleReplacementPlugin(),
    new RunScriptWebpackPlugin({ name: 'server.js' }),
  ],
  output: {
    path: path.join(__dirname, 'dist'),
    filename: 'server.js',
  },
};

这个配置告诉 webpack 关于我们的应用程序的一些基本信息。入口文件位于何处，应使用哪个目录保存已编译的文件，以及我们要使用哪种装载程序来编译源文件。基本上，您不必担心太多，根本不需要了解该文件的内容。

热模块更换

为了启用 HMR ，我们必须打开应用程序入口文件（ main.ts ），并添加一些与 Webpack 相关的说明。

declare const module: any;
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
  if (module.hot) {
    module.hot.accept();
    module.hot.dispose(() => app.close());
  }
}
bootstrap();

为了简化执行过程，请将两个脚本添加到 package.json 文件中。

"start:dev": "webpack --config webpack.config.js --watch"

现在，只需打开命令行并运行以下命令：

$ npm run start:dev

这里有一个可用的例子

mikroorm

(待翻译)

TypeORM

本章仅适用于TypeScript

!> 在本文中，您将学习如何使用自定义提供者机制从零开始创建基于 TypeORM 包的 DatabaseModule 。由于该解决方案包含许多开销，因此您可以使用开箱即用的 @nestjs/typeorm 软件包。要了解更多信息，请参阅 此处。

TypeORM 无疑是 node.js 世界中最成熟的对象关系映射器（ORM ）。由于它是用 TypeScript 编写的，所以它在 Nest 框架下运行得非常好。

入门

在开始使用这个库前，我们必须安装所有必需的依赖关系

$ npm install --save typeorm mysql2

我们需要做的第一步是使用从 typeorm 包导入的 createConnection() 函数建立与数据库的连接。createConnection() 函数返回一个 Promise，因此我们必须创建一个异步提供者)。

database.providers.ts

import { DataSource } from 'typeorm';
export const databaseProviders = [
  {
    provide: 'DATA_SOURCE',
    useFactory: async () => {
      const dataSource = new DataSource({
        type: 'mysql',
        host: 'localhost',
        port: 3306,
        username: 'root',
        password: 'root',
        database: 'test',
        entities: [
            __dirname + '/../**/*.entity{.ts,.js}',
        ],
        synchronize: true,
      });
      return dataSource.initialize();
    },
  },
];

!> 警告：设置 synchronize: true 不能被用于生产环境，否则您可能会丢失生产环境数据。

?> 按照最佳实践，我们在分离的文件中声明了自定义提供者，该文件带有 *.providers.ts 后缀。

然后，我们需要导出这些提供者，以便应用程序的其余部分可以 访问 它们。

database.module.ts

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';
@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

现在我们可以使用 @Inject() 装饰器注入 Connection 对象。依赖于 Connection 异步提供者的每个类都将等待 Promise 被解析。

存储库模式

TypeORM 支持存储库设计模式，因此每个实体都有自己的存储库。这些存储库可以从数据库连接中获取。

但首先，我们至少需要一个实体。我们将重用官方文档中的 Photo 实体。

photo.entity.ts

import { Entity, Column, PrimaryGeneratedColumn } from 'typeorm';
@Entity()
export class Photo {
  @PrimaryGeneratedColumn()
  id: number;
  @Column({ length: 500 })
  name: string;
  @Column('text')
  description: string;
  @Column()
  filename: string;
  @Column('int')
  views: number;
  @Column()
  isPublished: boolean;
}

Photo 实体属于 photo 目录。此目录代表 PhotoModule 。现在，让我们创建一个 存储库 提供者:

photo.providers.ts

import { DataSource } from 'typeorm';
import { Photo } from './photo.entity';
export const photoProviders = [
  {
    provide: 'PHOTO_REPOSITORY',
    useFactory: (dataSource: DataSource) => dataSource.getRepository(Photo),
    inject: ['DATA_SOURCE'],
  },
];

!> 请注意，在实际应用程序中，您应该避免使用魔术字符串。PhotoRepositoryToken 和 DbConnectionToken 都应保存在分离的 constants.ts 文件中。

在实际应用程序中，应该避免使用魔法字符串。PHOTO_REPOSITORY 和 DATABASE_CONNECTION 应该保持在单独的 constants.ts 文件中。

现在我们可以使用 @Inject() 装饰器将 Repository<Photo> 注入到 PhotoService 中：

photo.service.ts

import { Injectable, Inject } from '@nestjs/common';
import { Repository } from 'typeorm';
import { Photo } from './photo.entity';
@Injectable()
export class PhotoService {
  constructor(
    @Inject('PHOTO_REPOSITORY')
    private photoRepository: Repository<Photo>,
  ) {}
  async findAll(): Promise<Photo[]> {
    return this.photoRepository.find();
  }
}

数据库连接是 异步的，但 Nest 使最终用户完全看不到这个过程。PhotoRepository 正在等待数据库连接时，并且PhotoService 会被延迟，直到存储库可以使用。整个应用程序可以在每个类实例化时启动。

这是一个最终的 PhotoModule ：

photo.module.ts

import { Module } from '@nestjs/common';
import { DatabaseModule } from '../database/database.module';
import { photoProviders } from './photo.providers';
import { PhotoService } from './photo.service';
@Module({
  imports: [DatabaseModule],
  providers: [
    ...photoProviders,
    PhotoService,
  ],
})
export class PhotoModule {}

?> 不要忘记将 PhotoModule 导入到根 ApplicationModule 中。

Mongoose

!> 在本文中，您将学习如何使用自定义提供者机制从零开始创建基于 Mongoose 包的 DatabaseModule。由于该解决方案包含许多开销，因此您可以使用开箱即用的 @nestjs/mongoose 软件包。要了解更多信息，请参阅 此处。

Mongoose 是最受欢迎的MongoDB 对象建模工具。

入门

在开始使用这个库前，我们必须安装所有必需的依赖关系

$ npm install --save mongoose
$ npm install --save-dev @types/mongoose

我们需要做的第一步是使用 connect() 函数建立与数据库的连接。connect() 函数返回一个 Promise，因此我们必须创建一个 异步提供者)。

database.providers.ts

import * as mongoose from 'mongoose';
export const databaseProviders = [
  {
    provide: 'DATABASE_CONNECTION',
    useFactory: (): Promise<typeof mongoose> =>
      mongoose.connect('mongodb://localhost/nest'),
  },
];

?> 按照最佳实践，我们在分离的文件中声明了自定义提供者，该文件带有 *.providers.ts 后缀。

然后，我们需要导出这些提供者，以便应用程序的其余部分可以 访问 它们。

database.module.ts

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';
@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

现在我们可以使用 @Inject() 装饰器注入 Connection 对象。依赖于 Connection 异步提供者的每个类都将等待 Promise 被解析。

模型注入

使用Mongoose，一切都来自Schema。 让我们定义 CatSchema ：

schemas/cats.schema.ts

import * as mongoose from 'mongoose';
export const CatSchema = new mongoose.Schema({
  name: String,
  age: Number,
  breed: String,
});

CatsSchema 属于 cats 目录。此目录代表 CatsModule 。

现在，让我们创建一个 模型 提供者:

cats.providers.ts

import { Connection } from 'mongoose';
import { CatSchema } from './schemas/cat.schema';
export const catsProviders = [
  {
    provide: 'CAT_MODEL',
    useFactory: (connection: Connection) => connection.model('Cat', CatSchema),
    inject: ['DATABASE_CONNECTION'],
  },
];

!> 请注意，在实际应用程序中，您应该避免使用魔术字符串。CAT_MODEL 和 DATABASE_CONNECTION 都应保存在分离的 constants.ts 文件中。

现在我们可以使用 @Inject() 装饰器将 CAT_MODEL 注入到 CatsService 中：

cats.service.ts

import { Model } from 'mongoose';
import { Injectable, Inject } from '@nestjs/common';
import { Cat } from './interfaces/cat.interface';
import { CreateCatDto } from './dto/create-cat.dto';
@Injectable()
export class CatsService {
  constructor(
    @Inject('CAT_MODEL')
    private catModel: Model<Cat>,
  ) {}
  async create(createCatDto: CreateCatDto): Promise<Cat> {
    const createdCat = new this.catModel(createCatDto);
    return createdCat.save();
  }
  async findAll(): Promise<Cat[]> {
    return this.catModel.find().exec();
  }
}

在上面的例子中，我们使用了 Cat 接口。 此接口扩展了来自 mongoose 包的 Document ：

import { Document } from 'mongoose';
export interface Cat extends Document {
  readonly name: string;
  readonly age: number;
  readonly breed: string;
}

数据库连接是 异步的，但 Nest 使最终用户完全看不到这个过程。CatModel 正在等待数据库连接时，并且CatsService 会被延迟，直到存储库可以使用。整个应用程序可以在每个类实例化时启动。

这是一个最终的 CatsModule ：

cats.module.ts

import { Module } from '@nestjs/common';
import { CatsController } from './cats.controller';
import { CatsService } from './cats.service';
import { catsProviders } from './cats.providers';
import { DatabaseModule } from '../database/database.module';
@Module({
  imports: [DatabaseModule],
  controllers: [CatsController],
  providers: [
    CatsService,
    ...catsProviders,
  ],
})
export class CatsModule {}

?> 不要忘记将 CatsModule 导入到根 ApplicationModule 中。

Sequelize

SQL (Sequelize)

本章仅适用于 TypeScript

!> 在本文中，您将学习如何使用自定义提供者机制从零开始创建基于 Sequelize 包的 DatabaseModule。由于该解决方案包含许多开销，因此您可以使用开箱即用的 @nestjs/sequelize 软件包。要了解更多信息，请参阅 此处。

Sequelize 是一个用普通 JavaScript 编写的流行对象关系映射器( ORM )，但是有一个 Sequelize-TypeScript 包装器，它为基本 Sequelize 提供了一组装饰器和其他附加功能。

入门

要开始使用这个库，我们必须安装以下附件:

$ npm install --save sequelize sequelize-typescript mysql2
$ npm install --save-dev @types/sequelize

我们需要做的第一步是创建一个 Sequelize 实例，并将一个 options 对象传递给构造函数。另外，我们需要添加所有模型（替代方法是使用 modelPaths 属性）并同步数据库表。

database.providers.ts

import { Sequelize } from 'sequelize-typescript';
import { Cat } from '../cats/cat.entity';
export const databaseProviders = [
  {
    provide: 'SEQUELIZE',
    useFactory: async () => {
      const sequelize = new Sequelize({
        dialect: 'mysql',
        host: 'localhost',
        port: 3306,
        username: 'root',
        password: 'password',
        database: 'nest',
      });
      sequelize.addModels([Cat]);
      await sequelize.sync();
      return sequelize;
    },
  },
];

!> 按照最佳实践，我们在分隔的文件中声明了带有 *.providers.ts 后缀的自定义提供程序。

然后，我们需要导出这些提供程序，使它们可用于应用程序的其他部分。

import { Module } from '@nestjs/common';
import { databaseProviders } from './database.providers';
@Module({
  providers: [...databaseProviders],
  exports: [...databaseProviders],
})
export class DatabaseModule {}

现在我们可以使用 @Inject() 装饰器注入 Sequelize 对象。 每个将依赖于 Sequelize 异步提供程序的类将等待 Promise 被解析。

模型注入

在 Sequelize 中，模型在数据库中定义了一个表。该类的实例表示数据库行。首先，我们至少需要一个实体:

cat.entity.ts

import { Table, Column, Model } from 'sequelize-typescript';
@Table
export class Cat extends Model<Cat> {
  @Column
  name: string;
  @Column
  age: number;
  @Column
  breed: string;
}

Cat 实体属于 cats 目录。 此目录代表 CatsModule 。 现在是时候创建一个存储库提供程序了：

cats.providers.ts

import { Cat } from './cat.entity';
export const catsProviders = [
  {
    provide: 'CATS_REPOSITORY',
    useValue: Cat,
  },
];

?> 在实际应用中，应避免使用魔术字符串。 CATS_REPOSITORY 和 SEQUELIZE 都应保存在单独的 constants.ts 文件中。

在 Sequelize 中，我们使用静态方法来操作数据，因此我们在这里创建了一个别名。

现在我们可以使用 @Inject() 装饰器将 CATS_REPOSITORY 注入到 CatsService 中:

cats.service.ts

import { Injectable, Inject } from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto';
import { Cat } from './cat.entity';
@Injectable()
export class CatsService {
  constructor(
    @Inject('CATS_REPOSITORY') private readonly CATS_REPOSITORY: typeof Cat) {}
  async findAll(): Promise<Cat[]> {
    return this.catsRepository.findAll<Cat>();
  }
}

数据库连接是异步的，但是 Nest 使此过程对于最终用户完全不可见。 CATS_REPOSITORY 提供程序正在等待数据库连接，并且 CatsService 将延迟，直到准备好使用存储库为止。 实例化每个类时，启动整个应用程序。

这是最终的 CatsModule：