严格使用 GraphQL 作为查询语言

Posted

技术标签:

【中文标题】严格使用 GraphQL 作为查询语言【英文标题】:Using GraphQL strictly as a query language 【发布时间】:2018-06-14 11:24:13 【问题描述】:

我认为我的问题很常见,我正在权衡 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 是有价值还是愚蠢?

【问题讨论】:

【参考方案1】:

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

顺便说一句,我不确定QueryIDL 会是什么...查询只是一个字符串。不需要专门的课程。

【讨论】:

非常感谢!是的,我在一家很小的公司工作,很少接触 GraphQL,所以我想要一个健全性检查比什么都重要,因为我经常看到“GraphQL Server”这个短语飞来飞去。我很感激!

以上是关于严格使用 GraphQL 作为查询语言的主要内容,如果未能解决你的问题,请参考以下文章

GraphQL查询语言中的CSRF漏洞

一种用于 API 的查询语言-GraphQL

当下最流行的API查询语言GraphQL-再不用你就out了

开放API 与 查询语言GraphQL

新 GraphQL buildSchema 的嵌套查询

GraphQL新手上路