严格使用 GraphQL 作为查询语言

Question

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

我正在开发一种产品，其数据由基于 CRUD 的整体式 REST 存储 API。我们的应用程序组件公开了数据搜索界面，当然需要某种服务器端支持来请求该数据。这可能包括排序、过滤、选择字段等。当然，还有更传统的方法可以在 REST 上下文中提供这些功能，例如端点的查询参数附加组件，但在此尝试 GraphQL 会很酷上下文为扩展其查询位的用途奠定基础。

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();
  }

我正计划将一个请求正文放入我的 Jersey 服务器，它看起来与将发送到 GraphQL 服务器的请求完全一样。然后我利用一些库支持来解释和执行数据请求。

没有真正考虑太多可能出错的事情，看起来客户端可以使用这个 API 类似于他们使用 GraphQL 服务器的方式，除了我不需要管理一个单独的服务器只是为了方便我的搜索需求。

像这样在基于端点的上下文中使用 GraphQL IDL 看起来有价值还是愚蠢？

Answer 1

除了不需要在每次请求时重建架构或 GraphQL 实例（有些情况下您可能想要重建 GraphQL 实例，但您的情况并非如此） , 这几乎是规范的使用方式。
为 GraphQL 保留一个单独的服务器是相当不常见的，并且它通常完全按照您描述的方式引入 - 作为您通常的 REST 端点旁边的另一个端点。所以你的用法是合法的——一点也不傻:)

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

严格使用 GraphQL 作为查询语言

Using GraphQL strictly as a query language

rest

graphql

jersey-2.0

graphql-java