严格使用 GraphQL 作为查询语言

Question

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

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

GraphQL 公开了一种非常好的查询语言来搜索数据，并最终允许我专门针对我的领域定制搜索语言。但是，我不确定是否有一种很好的方法来利用 IDL 而无需完全管理单独的服务器。

以下面的 Java Jersey API Proof-of-Concept 为例：

  @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 会是什么...查询只是一个字符串。不需要专门的课程。