工具

工具

在GraphQL世界中，很多文章抱怨如何处理诸如身份验证或操作的副作用之类的东西。我们应该把它放在业务逻辑中吗？我们是否应该使用更高阶的函数来增强查询和突变，例如，使用授权逻辑？或者也许使用模式指令。无论如何，没有一个答案。

Nest生态系统正试图利用守卫和拦截器等现有功能帮助解决这个问题。它们背后的想法是减少冗余，并为您提供有助于创建结构良好，可读且一致的应用程序的工具。

概观

您可以使用与简单REST应用程序相同的方式使用警卫，拦截器和管道。此外，您可以通过利用自定义装饰器功能轻松创建自己的装饰器。他们都行为相当。我们来看看下面的代码：

@Query('author')
@UseGuards(AuthGuard)
async getAuthor(@Args('id', ParseIntPipe) id: number) {
  return await this.authorsService.findOneById(id
}

如您所见，GraphQL在防护和管道方面都能很好地工作。因此，您可以将身份验证逻辑移至防护，甚至可以重用与REST应用程序相同的防护类。拦截器的工作方式完全相同：

@Mutation()
@UseInterceptors(EventsInterceptor)
async upvotePost(@Args('postId') postId: number) {
  return await this.postsService.upvoteById{ id: postId }
}

执行上下文

但是，ExecutionContext守卫和拦截器所接收的情况有所不同。GraphQL解析器有一个单独的参数集，分别为root，args，context，和info。因此，我们需要将给定转换ExecutionContext为GqlExecutionContext，这基本上非常简单。

import { CanActivate, ExecutionContext, Injectable } from '@nestjs/common';
import { GqlExecutionContext } from '@nestjs/graphql';

@Injectable()
export class AuthGuard implements CanActivate {
  canActivate(context: ExecutionContext): boolean {
    const ctx = GqlExecutionContext.create(context
    return true;
  }
}

GqlExecutionContext为每个参数公开相应的方法，比如getArgs()，getContext()等等。现在，我们可以毫不费力地获取特定于当前处理的请求的每个参数。

自定义装饰器

如前所述，自定义装饰器功能也可以像GraphQL解析器一样工作。但是，工厂函数采用一组参数而不是request对象。

export const User = createParamDecorator(
  (data, [root, args, ctx, info]) => ctx.user,

接着：

@Mutation()
async upvotePost(
  @User() user: UserEntity,
  @Args('postId') postId: number,
) {}