在GraphQL（四）：GraphQL工程化实践中说到权限管理，是用 Instrumentation 来实现，这其实是很坑的，因为API和权限的关系需要自己实现，如果能够像spring注解一样，直接在定义API的时候就关联上相应的权限，然后在后端根据用户权限和API权限做判断，那么现有的spring的权限控制的逻辑都可以复用，并且要扩展更多需求也更优雅。说到底，根本上是期望能够有一种更便捷的方式拦截GraphQL的API。
Derectives
在GraphQL规范中有定义一个叫做Derectives的家伙
Directives provide a way to describe alternate runtime execution and type validation behavior in a GraphQL document.
乍一看，这不就是我们需要的功能吗？
然而，这个这么有用的功能GraphQL-Java在9.0版本才实现，实在是姗姗来迟啊。而如果是通过GraphQL-Java-Tools来使用GraphQL需要使用5.2.4以上的版本才能享受Derectives。
利用Derectives实现GraphQLAPI拦截
总共分成三个步骤：
1. 在schema中定义并使用Derectives
directive @role(roles : [Int!]!) on FIELD_DEFINITION
type Query{
stages:[Stage!]! @role(roles : [101])
subjects:[Subject!]! @role(roles : [100]) @deprecated(reason:"is old value")
}
我们定义了一个叫做“role"的Derective，它带有一个Int的数组作为参数。当我们在API上使用Derective，通过不同的参数就可以区分不同的权限。
2. 实现Derective的拦截
class RoleDirective : SchemaDirectiveWiring {
override fun onField(environment: SchemaDirectiveWiringEnvironment?): GraphQLFieldDefinition {
val targetRoles = environment!!.directive.getArgument("roles").value
val field = environment!!.element
val originalDataFetcher = field.dataFetcher
val dataFetcher = DataFetcher {
val user = AuthInfoHolder.authInfo.user
val userRole= getUserRole(user)
val requireRoles = targetRoles as List
if (!requireRoles.contains(userRole)) {
throw Exception("requireRoles")
}
originalDataFetcher.get(it)
}
return field.transform { it.dataFetcher(dataFetcher) }
}
}
SchemaDirectiveWiring 是充当胶水的一个类，它将schema中的Derective和GraphQL引擎关联起来。
3. 将RoleDirective注入GraphQL引擎
如果是用GraphQL-Java-Tools，在构建SchemaParserBuilder时直接注入：
schemaParserBuilder.resolvers(resolvers!!)
.directive("role", RoleDirective())
.build()
如果没用GraphQL-Java-Tools呢？这就要做更多的事情了，在介绍原理时再来介绍这部分。
Derectives原理（基于GraphQl-JAVA-TOOLS 5.5.2）
在介绍Derectives原理前需要了解一个概念：DataFetcher。
GraphQL通过DataFetcher获取每一个字段的值，比如上面的stages、subjects，包括stage里面的子属性stageId、stageName等，都对应了一个DataFetcher。后续会专门写一篇文章来介绍DataFetcher，这里先简单了解。
回到上面第二步的代码：
class RoleDirective : SchemaDirectiveWiring {
// 重写onField方法，拦截标记了Directive的API
override fun onField(environment: SchemaDirectiveWiringEnvironment?): GraphQLFieldDefinition {
// 获取Directive中的参数值（类似于获取注解中的参数值）
val targetRoles = environment!!.directive.getArgument("roles").value
val field = environment!!.element
// 获取原来的DataFetcher
val originalDataFetcher = field.dataFetcher
// 包装了原始DataFetcher的新的DataFetcher
val dataFetcher = DataFetcher {
val user = AuthInfoHolder.authInfo.user
val userRole= getUserRole(user)
val requireRoles = targetRoles as List
// 如果没有权限则抛出异常
if (!requireRoles.contains(userRole)) {
throw Exception("requireRoles")
}
// 如果有权限则走原始DataFetcher的数据获取逻辑
originalDataFetcher.get(it)
}
// 将原来的DataFetcher替换成增加了拦截功能的新的DataFetcher
return field.transform { it.dataFetcher(dataFetcher) }
}
}
类似增加了一个代理，在代理中处理了权限拦截。
前面的文章有说过，Instrumentation也可以在获取数据前做拦截，它和Derective的区别在于后者是配合了schema中定义的Derective，而前者是纯后端对整个流程的拦截。
除了Field，SchemaDirectiveWiring 还允许我们拦截对象、参数、枚举等等。那么，当我们把Directive注入到GraphQL引擎后，是怎么影响到GraphQL的执行流程的呢？
我们写的 SchemaDirectiveWiring 会和其他用户自定义的东东（ GraphQLScalarType、typeResolvers、EnumValuesProvider 等）包装成一个 RuntimeWiring ，一看名字就是做注入的，接着 RuntimeWiring 被传递到 SchemaParser 中， SchemaParser 会把从schema解析得到的对象构造成内存中的 GraphQLSchema，核心的方法是 parseSchemaObjects()：
fun parseSchemaObjects(): SchemaObjects {
// 省略...
// 创建不同的GraphQLType Object
val interfaces = interfaceDefinitions.map { createInterfaceObject(it) }
val objects = objectDefinitions.map { createObject(it, interfaces) }
val unions = unionDefinitions.map { createUnionObject(it, objects) }
val inputObjects = inputObjectDefinitions.map { createInputObject(it) }
val enums = enumDefinitions.map { createEnumObject(it) }
// 省略...
}
我们把焦点集中到 createObject 上，这里的Object指的是我们在schema中定义的type，比如：
## 这是一个叫Stage的Object
type Stage{
stageCode:String
stageName:String
}
## 这是一个叫Query的Object
type Query{
stages:[Stage!]! @role(roles : [101])
subjects:[Subject!]! @role(roles : [100]) @deprecated(reason:"is old value")
}
我们截取 createObject 中的代码进行分析：
private fun createObject(definition: ObjectTypeDefinition, interfaces: List): GraphQLObjectType {
// 解析到Query这个Object，建造者模式构造一个GraphQLObjectType
val name = definition.name
val builder = GraphQLObjectType.newObject()
.name(name)
.definition(definition)
.description(if (definition.description != null) definition.description.content else getDocumentation(definition))
// 注入绑定到Object上的Derective
builder.withDirectives(*buildDirectives(definition.directives, setOf(), Introspection.DirectiveLocation.OBJECT))
// 注入实现的接口
definition.implements.forEach { implementsDefinition ->
val interfaceName = (implementsDefinition as TypeName).name
builder.withInterface(interfaces.find { it.name == interfaceName }
?: throw SchemaError("Expected interface type with name '$interfaceName' but found none!"))
}
// 这里是重点啦，这里会找到当前Object的字段的FieldDefinition
definition.getExtendedFieldDefinitions(extensionDefinitions).forEach { fieldDefinition ->
fieldDefinition.description
// 根据schema的FieldDefinition构造GraphQLFieldDefinition，也就是构造stages这个API，不过对于GraphQL来讲，都是GraphQLFieldDefinition
builder.field { field ->
createField(field, fieldDefinition)
field.dataFetcher(fieldResolversByType[definition]?.get(fieldDefinition)?.createDataFetcher()
?: throw SchemaError("No resolver method found for object type '${definition.name}' and field '${fieldDefinition.name}', this is most likely a bug with graphql-java-tools"))
// 将经过SchemaDirectiveWiring处理的stages的GraphQLFieldDefinition返回
val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring))
GraphQLFieldDefinition.Builder(wiredField)
.clearArguments()
.argument(wiredField.arguments)
}
}
val objectType = builder.build()
return directiveGenerator.onObject(objectType, DirectiveBehavior.Params(runtimeWiring))
}
沿着 val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring)) 继续跟，跟到 SchemaGeneratorDirectiveHelper 中找到了 SchemaDirectiveWiring 的处理：
private T wireForEachDirective(
Parameters parameters, T element, List directives,
EnvBuilder envBuilder, EnvInvoker invoker) {
T outputObject = element;
for (GraphQLDirective directive : directives) {
SchemaDirectiveWiringEnvironment env = envBuilder.apply(outputObject,directive);
Optional directiveWiring = discoverWiringProvider(parameters, directive.getName(), env);
if (directiveWiring.isPresent()) {
SchemaDirectiveWiring schemaDirectiveWiring = directiveWiring.get();
// 执行SchemaDirectiveWiring中的onField方法，完成DataFetcher的拦截
T newElement = invoker.apply(schemaDirectiveWiring, env);
assertNotNull(newElement, "The SchemaDirectiveWiring MUST return a non null return value for element '" + element.getName() + "'");
outputObject = newElement;
}
}
return outputObject;
}
我们回到最开始的问题，如果没用GraphQL-Java-Tools怎么注入 SchemaDirectiveWiring 呢？
答案就很显然了，我们需要自己写 GraphQLFieldDefinition，然后自己调用 val wiredField = directiveGenerator.onField(field.build(), DirectiveBehavior.Params(runtimeWiring)) 即可，调用 directiveGenerator 很简单，但是每一个 GraphQLFieldDefinition 都要自己写就比较麻烦了。