GraphQL有自己查询语法,发起的API请求中通过传递查询语句来告诉服务端需要哪些操作和具体数据字段,GraphQL定义了实现规范,各种的语言分别实现了GraphQL功能框架,通过框架可以对查询语法进行解释执行,然后返回数据输出给客户端。
Client通过rest api去服务端请求非规范化的数据,随着应用的发展,很快遇到了网络带宽瓶颈,client需要获取比以往更多的非规范化数据。
因为并非所有页面都需要所有数据,所以可以针对每个页面的实际情况规范化数据,减少发送给client的字段数量。传统的做法是,针对每个页面定义相应的端点(数据接口),这个不好维护,不是一个好的解决方案;另一个做法是在client和server之间加入一个中间层graphql服务层,如图:
引入 GraphQL 不仅解决了网络带宽瓶颈问题,而且还提供了很多其他优势,让我们能够更快地添加功能。比如:提高开发速度和整体页面的加载性能。
GraphQL服务API可以通过语句查询出它所支持的类型,开发可以不需要花时间写API文档,GraphQL直接帮助开发者快速了解API。
#查询语句
{
__type(name: “MStudentType”) {
kind
name
fields {
name
description
type {
name
}
}
}
}
基于自检性,GraphQL开源了辅助工具GraphiQL,方便GraphQL接口调试和自动生成接口文档
GraphQL辅助工具:GraphiQL,可以调试查询语句,并对接口定义的schema进行文档可视化展示
o查询语句进行感知
o错误提示
o语句格式化
o执行查询
o查看接口定义的schema文档信息
可以理解为数据库中的表,描述了数据的结构。graphql通过schema描述了可以提供的数据,可以查询到哪些对象,对象中有哪些字段。
每一个 GraphQL 服务都会定义一套类型,用以描述你可能从那个服务查询到的数据。每当查询到来,服务器就会根据 schema 验证并执行查询。
与查询语言相似,用于定义数据类型。
通常,某些机器比其他机器更适合用来完成某些任务。当我们引入 GraphQL 中间层后,GraphQL 服务器仍然需要调用与客户端相同的服务和 REST API。现在的区别在于,大部分数据的流动是在同一数据中心内的服务器之间。这些服务器到服务器之间的调用具有非常低的延迟,而且带宽非常高,与来自浏览器的直接网络调用相比,性能提升了很多。
GraphQL 允许客户端选择它需要的数据,所以我们只需要获取更小的有效载荷。这些变更是以提高服务器利用率为代价的,服务器需要进行数据的获取和聚合,不过虽然牺牲了这额外的几毫秒服务器时间,却换来了较小的客户端有效载荷。
通过分析查询语句就知道输出的数据内容字段有哪些
可以自定义查询语句来获取需要使用的字段,避免无用字段的输出,减少不必要数据块/数据字段查询逻辑
https://www.apollographql.com/