严格使用GraphQL作为查询语言

Question

我认为我的问题是一个常见的问题，我正在权衡作为解决方案的GraphQL的成本和收益。

我在一个产品上工作，该产品的数据由基于CRUD的RESTAPI存储。我们的应用程序组件公开了一个数据搜索接口，当然需要某种服务器端支持来请求该数据。这可以包括排序、筛选、选择字段等。当然，在Hibernate上下文中提供这些功能的更传统方式，比如endpoint的查询参数附加项，但是在这一上下文中尝试CopyQL是很酷的，这为扩展其查询查询的使用奠定了基础。

GraphQL为数据搜索提供了一种非常好的查询语言，并最终允许我专门针对我的领域定制搜索语言。但是，我不确定是否有一种不用管理单独的服务器就可以利用IDL的好方法。

以以下Java Jersey API概念验证示例为例：

  @GET
  @Path("/api/v1/search")
  public Response search(QueryIDL query) throws IOException {
    final SchemaParser schemaParser = new SchemaParser();

    TypeDefinitionRegistry typeDefinitionRegistry = // load schema
    RuntimeWiring runtimeWiring = // wire up data-fetching classes
    SchemaGenerator schemaGenerator = new SchemaGenerator();
    GraphQLSchema graphQLSchema =
        schemaGenerator.makeExecutableSchema(typeDefinitionRegistry, runtimeWiring);
    GraphQL build = GraphQL.newGraphQL(graphQLSchema).build();

    ExecutionResult executionResult = build.execute(query.toString());

    return Response.ok(executionResult.getData()).build();
  }

我只是计划采取一个请求体到我的泽西服务器，看起来完全一样的请求，将被发送到GraphQL服务器。然后，我利用一些库支持来解释和执行对数据的请求。

如果不想太多可能出错的事情，看起来客户机可以像使用GraphQL服务器一样使用此API，只是我不需要管理单独的服务器来满足搜索需求。

在这样一个基于endpoint的上下文中使用GraphQL IDL是有价值的还是愚蠢的？

Answer 1

除了不需要在每个请求上重建模式或GraphQL实例（有些情况下，您可能想要重建GraphQL实例，但您的情况不是这样），这几乎是规范的方式
为GraphQL保留一个单独的服务器是相当不常见的，它通常会按照您描述的方式进行介绍——就像您通常的RESTendpoint旁边的另一个endpoint一样。所以你的用法是合法的-一点也不傻：）

顺便说一句，我不确定什么是QueryIDL。。。查询只是一个字符串。不需要特别的课程。