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

严格使用GraphQL作为查询语言

1 个答案: