Demo到产品化还有很长的路要走,尤其是要在尽量小的影响当前框架的前提下引入新的方法。
GraphiQL是整个GraphQL优势的重要一环,然而默认的GraphiQL不允许配置graphql服务的地址(就是点击GraphiQL上的运行按钮去请求数据的地址),要弄明白这一点很容易,找到graphiql-spring-boot-autoconfigure包,里面有graphiql.html文件,请求数据的endpoint是硬编码的:
function graphQLFetcher(graphQLParams) {
// This example expects a GraphQL server at the path /graphql.
// Change this to point wherever you host your GraphQL server.
return fetch('/graphql', {
method: 'post',
headers: {
'Accept': 'application/json',
'Content-Type': 'application/json',
},
body: JSON.stringify(graphQLParams),
credentials: 'include',
}).then(function (response) {
return response.text();
}).then(function (responseBody) {
try {
return JSON.parse(responseBody);
} catch (error) {
return responseBody;
}
});
}
显然这不能满足项目工程化的要求,解决这个问题有两种比较简单的方式:
强大的实体关系图生成工具
GitHub已经提供了GraphQL的接口,实体关系图可以在GraphQL Voyager里查看,Custom Schema允许提供自己的实体关系数据生成实体关系图,简直不能更好用。
在GraphQL(三):GraphQL集成SpringBoot原理中提到GraphQL本身不带身份认证和权限控制(这也确实不是它该做的事儿),但是它对查询提供了回调方法(Instrumentation接口),在GraphQL.java文件中可以看到这部分逻辑:
public ExecutionResult execute(String requestString, String operationName, Object context, Map<String, Object> arguments) {
//执行回调
InstrumentationContext<ExecutionResult> executionCtx = instrumentation.beginExecution(new ExecutionParameters(requestString, operationName, context, arguments));
assertNotNull(arguments, "arguments can't be null");
log.debug("Executing request. operation name: {}. Request: {} ", operationName, requestString);
//解析回调
InstrumentationContext<Document> parseCtx = instrumentation.beginParse(new ExecutionParameters(requestString, operationName, context, arguments));
Parser parser = new Parser();
Document document;
try {
document = parser.parseDocument(requestString);
parseCtx.onEnd(document);
} catch (ParseCancellationException e) {
RecognitionException recognitionException = (RecognitionException) e.getCause();
SourceLocation sourceLocation = new SourceLocation(recognitionException.getOffendingToken().getLine(), recognitionException.getOffendingToken().getCharPositionInLine());
InvalidSyntaxError invalidSyntaxError = new InvalidSyntaxError(sourceLocation);
return new ExecutionResultImpl(Collections.singletonList(invalidSyntaxError));
}
//验证回调
InstrumentationContext<List<ValidationError>> validationCtx = instrumentation.beginValidation(new ValidationParameters(requestString,operationName,context,arguments,document));
Validator validator = new Validator();
List<ValidationError> validationErrors = validator.validateDocument(graphQLSchema, document);
validationCtx.onEnd(validationErrors);
if (validationErrors.size() > 0) {
return new ExecutionResultImpl(validationErrors);
}
ExecutionId executionId = idProvider.provide(requestString, operationName, context);
Execution execution = new Execution(queryStrategy, mutationStrategy, subscriptionStrategy, instrumentation);
ExecutionResult result = execution.execute(executionId, graphQLSchema, context, document, operationName, arguments);
executionCtx.onEnd(result);
return result;
}
通过对每次执行GraphQL查询进行拦截可以实现类似SpringMVC拦截器的效果,但是需要自己实现SpringMVC中 @RequiredRole 注解的功能。
在GraphQL(二):GraphQL服务搭建中提到有两种搭建GraphQL服务的方式,当时并没有考虑身份认证和权限控制的问题,假如要在那两种方法的基础上加入身份认证和权限控制,有哪些成本呢?
综合来看:
ok,再想想我们的需求是什么。
这么一看的话可以得出这样的方案:
可以同时使用SpringMVC的拦截器和graphql-java-tools的优势。
似乎这种方案能满足我们的需求,但是有一个潜在的风险:
“A用户允许访问ApiA,ApiA能够访问到实体A,但是A用户没有权限访问实体A”
这时工程上就难以控制了,如果非要控制需要对实体进行权限,能做到,但是需要另外一套设计,工作量也不小。
工程化实践时风险是必须要考虑的问题,GraphQL强大的自省功能(查询整个实体图的结构)能方便开发,也带来了相应的风险,同时嵌套循环查询、sql注入等问题也是需要防范的。