大家好,我的nestjs应用程序中存在冲突/覆盖问题。
那么,问题是什么:
我有一个解析器
@Resolver('ResolverA')
export class SomePageResolver {
constructor(private readonly someService: someService) {
}
@Query(() => someType)
theThingThatMessesUpStuff(
@Args('params') params: HttpParamsInput,
@Context(TokenPipe) authorization: string,
): Observable<ActionSetsPageType> {
return this.someService.doSomething(params, authorization)
}
}
和解析器b
@Resolver('ResolverB')
export class SomePageResolver{
constructor(private readonly someService: someService) {
}
@Query(() => someOtherType)
theThingThatMessesUpStuff(
@Args('params') params: HttpParamsInput,
@Context(TokenPipe) authorization: string,
): Observable<ActionSetsPageType> {
return this.someService.doSomethingElse(params, authorization)
}
}
分别地 Resolver A
是 Module A
及 Resolver B
是 Module B
.
根据我拥有的版本,两者都有可能 Module A
及 Module B
在单个模块(单亲模块)中导入,这会导致覆盖问题。问题的实质是,当两个模块都是构建的一部分时,如果客户机查询 theThingThatMessesUpStuff
它将使用最后导入的模块进行查询
// some code
@Module({
imports: [
// some imports
ModuleB,
ModuleA
]
})
// some more code
如果使用上面的示例配置,则每当客户端尝试查询 theThingThatMessesUpStuff
字段,查询将由内部的实现解决 ModuleA
,其中对于某些功能(在与此构建相关的前端内部),客户机希望在内部实现 ModuleB
现在回到主要问题,是否有一种不需要太多人参与的方法来创建一个验证,以保证在nestjs应用程序的范围内只存在唯一的gql查询。
1条答案
按热度按时间t3psigkw1#
到目前为止,我已经找到了两种解决方案:
以某种方式在项目的所有团队和人员中实施一种命名约定,以某种前缀的形式,只要每个团队成员都知道并保持警惕,这种命名约定就会起作用。
创建decorator函数并修饰所有查询
而这个东西也会这样使用
有了这个解决方案,开发人员应该再次提高警惕,在任何地方都使用decorator,而且这个decorator应该应用于整个代码库,以实现一致性(这是一项非常不愉快的任务)。