摘要:系列文章核心概念本文浅尝最近因为工作上新产品的需要,让我有机会了解和尝试。这篇文章主要分享的是的核心概念,主要分为和四部分。再次强调,本文主要讲的是的核心概念,中所定义的类,都是设计类,并不是具体实现代码。
A query language created by Facebook for describing data requirements on complex application data models
系列文章:
GraphQL 核心概念(本文)
graphql-js 浅尝
最近因为工作上新产品的需要,让我有机会了解和尝试 GraphQL。按照套路,在介绍一项新技术的时候总要回答 3 个问题:What, Why & How。
What is GraphQL?正如副标题所说,GraphQL 是由 Facebook 创造的用于描述复杂数据模型的一种查询语言。这里查询语言所指的并不是常规意义上的类似 sql 语句的查询语言,而是一种用于前后端数据查询方式的规范。
Why using GraphQL?当今客户端和服务端主要的交互方式有 2 种,分别是 REST 和 ad hoc 端点。GraphQL 官网指出了它们的不足之处主要在于:当需求或数据发生变化时,它们都需要建立新的接口来适应变化,而不断添加的接口,会造成服务器代码的不断增长,即使通过增加接口版本,也并不能够完全限制服务器代码的增长。(更多不足,前往官网查看)
既然,GraphQL 指出了它们的缺点,那么它自然解决了这些问题。
如何解决的哪?那就得说说 GraphQL 的 3 大特性。
首先,它是声明式的。查询的结果格式由请求方(即客户端)决定而非响应方(即服务器端)决定,也就是说,一个 GraphQL 查询结果的返回是同客户端请求时的结构一样的,不多不少,不增不减。
其次,它是可组合的。一个 GraphQL 的查询结构是一个有层次的字段集,它可以任意层次地进行嵌套或组合,也就是说它可以通过对字段进行组合、嵌套来满足需求。
第三,它是强类型的。强类型保证,只有当一个 GraphQL 查询满足所设定的查询类型,那么查询的结果才会被执行。
回到之前的问题,也就是说,当需求或数据发生变化时,客户端可以根据需求来改变查询的结构,只要查询结构满足之前的定义,服务器端代码甚至不需要做任何的修改;即使不满足,也只需修改服务器端的查询结构,而不必额外添加新的接口来满足需求。
Core Concepts可能你会问,按套路这节不该是 HOW to use GraphQL,怎么变成了 Core Concepts?
由于,GraphQL 是一种规范,于是,它的实现不限制某种特定语言,每种语言对 GraphQL 都可以有自己的实现,比如相对 JavaScript 就有 graphql-js。既然,实现都不相同,那么,使用的方法也会不同,所以便不在这里细述了。
这篇文章主要分享的是 GraphQL 的核心概念,主要分为:Type System, Query Syntax, Validation 和 Introspection 四部分。
Type System类型系统是整个 GraphQL 的核心,它用来定义每个查询对象和返回对象的类型,将所有定义的对象组合起来就形成了一整个 GraphQL Schema。
这个概念比较抽象,空说很难理解,还是拿例子来边看边说。个人博客相信大家都很熟悉,这里就尝试用一个简单的博客系统的例子来说明,这会比官网星战的例子简单一点。
Let"s go!
既然是一个博客,那么,文章肯定少不了,我们首先来建立一个文章的类型。
type Post { id: String, name: String, createDate: String, title: String, subtitle: String, content: String }
这样,一个简单的文章类型就定义好了,它是一个自定义的类型,包含了一系列的字段,巧合的是这些字段的类型正好都是 String(字符串类型)。
String 没有定义过,为什么可以直接使用哪?因为,String 是 GraphQL 支持的 scalar type(标量类型),默认的标量类型还包括 Int,Float, Boolean 和 ID。
许多的博客网站都支持给每篇文章打标签,那么我们在来建立一个标签的类型。
type Tag { id: String, name: String, label: String, createDate: String }
标签类型和文章类型怎么整合到一起哪?
GraphQL 不单单支持简单类型,还支持一些其他类型,如 Object, Enum, List, NotNull 这些常见的类型,还有 Interface, Union, InputObject 这几个特殊类型。
PS:一直没搞明白 Interface 和 Union 的区别在哪,它们分别适用于什么场景?谷歌了一下,还真有篇文章说它们的区别,不过恕我愚钝,还是没能领悟,还望大神点拨...
再修改一下之前的文章类型,使一个文章可以包含多个标签。
type Post { id: String, name: String, createDate: String, title: String, subtitle: String, content: String, tags: [Tag] }
通常在博客网站的标签列表中会显示该标签下的一些文章,由于 GraphQL 是以产品为中心的,那么在标签类型下也可以有文章类型。于是,标签类就变成了
type Tag { id: String, name: String, label: String, createDate: String, posts: [Post] }
可能你会疑惑,文章类型和标签类型这样相互嵌套会不会造成死循环?我可以负责任的告诉你:不会。你可以尽情地嵌套、组合类型结构来满足你的需求。
最后,根据整个博客网站的需求,组合嵌套刚刚定义的文章类型和标签类型,建立一个根类型作为查询的 schema。
type Blog { post: Post, // 查询一篇文章 posts: [Post], // 用于博客首页,查询一组文章 tag: Tag, // 查询一个标签 tags: [Tag], // 用于博客标签页,查询所有标签 }
OK,我们的类型和 schema 都定义好了,就可以开始查询了。怎么查哪?那我们来看看 GraphQL 的查询语法。
Query SyntaxGraphQL 的查询语法同我们现在所使用的有一大不同是,传输的数据结构并不是 JSON 对象,而是一个字符串,这个字符串描述了客户端希望服务端返回数据的具体结构。
知道了概念,那么一个 GraphQL 的查询到底长什么样哪?继续我们的例子,假设,我们现在要查询一篇文章,那么,GraphQL 的查询语句就可以是这样。
query FetchPostQuery { post { id, name, createDate, title, subtitle, content, tags { name, label } } }
它相对应的返回就会是类似这样的一个 JSON 数据。
{ "data": { "post": { "id": "3", "name": "graphql-core-concepts", "createDate": "2016-08-01", "title": "GraphQL 核心概念", "subtitle": "A query language created by Facebook for decribing data requirements on complex application data models", "content": "省略...", "tags": [{ "name": "graphql", "label": "GraphQL" }] } } }
从中我们可以看到,数据返回了整个文章的属性以及部分的标签属性。其中,标签属性并没有返回全部的字段,而是只返回了 name 和 label 字段的属性,做到了返回数据的结构完成同请求数据的结构相同,没有冗余的数据。
查询添加参数的需求也非常基本,在 GraphQL 的查询语法中也相当简单,就拿刚刚的例子,要查询特定的文章就可以把它改成这样。
query FetchPostQuery { post(name: "graphql-core-concepts") { id, name, createDate, title, subtitle, content, tags { name, label } } }
返回的结果会是和之前的一样。查询关键字只有在多个查询时才必须,在单个查询时可以省略。同时,也可以对查询的返回起别名,再来看看博客的首页希望展示一个粗略的文章列表,那么这样的一个查询语句可以是
{ postList: posts { id, name, createDate, title, subtitle, tags { name, label } } }
这里,我们省略了查询关键字,并将 posts 起了一个别名为 postList,返回的结果就会是
{ "data": { "postList": [{ "id": "3", "name": "graphql-core-concepts", "createDate": "2016-08-01", "title": "GraphQL 核心概念", "subtitle": "A query language created by Facebook for decribing data requirements on complex application data models", "tags": [{ "name": "graphql", "label": "GraphQL" }] }, { "id": "2", "name": "redux-advanced", "createDate": "2016-07-23", "title": "Redux 进阶", "subtitle": "Advanced skill in Redux", "tags": [{ "name": "javascript", "label": "JavaScript" }, { "name": "redux", "label": "Redux" }, { "name": "state-management", "label": "State management" }, { "name": "angular-1.x", "label": "Angular 1.x" }, { "name": "ui-router", "label": "ui-router" }, { "name": "redux-ui-router", "label": "redux-ui-router" }] }, { "id": "1", "name": "getting-started-with-redux", "createDate": "2016-07-06", "title": "Redux 入门", "subtitle": "A tiny predictable state management lib for JavaScript apps", "tags": [{ "name": "javascript", "label": "JavaScript" }, { "name": "redux", "label": "Redux" }, { "name": "state-management", "label": "State management" }, { "name": "angular-1.x", "label": "Angular 1.x" }] }] } }
同样,查询所有标签的语句就可以是这样
{ tags { id, name, label, posts { name, title } } }
这样,一个 GraphQL 的接口,满足了一个简单博客网站的所有需求,是不是很神奇?
Validation由于 GraphQL 是一个强类型语言,所以它可以在执行查询之前检查每个查询语句是否满足事先设定的 schema,符合则合法,如果查询语句不合法则不进行查询。
以上所举的都是合法的例子,官网上举了一些例子,这里就不贴了,我们就总结看看要注意的有哪几点。
fragment 不能引用自己从而形成一个循环
不能查询类型中不存在的字段
查询的字段如果不是 scalar type(标量类型)或 enum type(枚举类型),则需要明确该字段下所包含的字段
同上一条相对,如果查询字段是 scalar type(标量类型),那么它就不能再有子字段
IntrospectionIntrospection 这个词的意思是内省,自我检查(第一次发现英语有语义如此丰富的词,又暴露词汇量少了-_-||)。
不扯远了,在 GraphQL 中 Introspection 是一个非常有用的功能,它可以用来查询当前 GraphQL 的 schema,从而得知服务器端支持何种类型的查询。
这是一个非常强大且有用的功能,可以想象一下,现在大型公司的开发基本上都是前后端分离的,客户端并不知道服务器端提供的 schema 结构,但通过 Introspection,客户端就能获得当前服务器端所提供的 schema,这无论对开发,还是调试错误都很有帮助。
还是拿刚刚的博客系统来做例子,我们可以通过查询 __schema 字段来获得当前所支持的查询类型。
// query string { __schema { types { name } } } // response data { "data": { "__schema": { "types": [ { "name": "String" }, { "name": "BlogType" }, { "name": "PostType" }, { "name": "ID" }, { "name": "TagType" }, { "name": "__Schema" }, { "name": "__Type" }, { "name": "__TypeKind" }, { "name": "Boolean" }, { "name": "__Field" }, { "name": "__InputValue" }, { "name": "__EnumValue" }, { "name": "__Directive" }, { "name": "__DirectiveLocation" } ] } } }
从返回的数据中可以看到,我们自定义的 BlogType, PostType 和 TagType 类,剩下的都是 GraphQL 内部类型,其中又分为两类:一类是 ID, String 和 Bealoon 所表示的标量类型,另一类以双下划线开头的是用于自我检查的类型。
知道了自定义类,假设,还想知道自定义类中包含哪些属性以及属性的类型,就可以这样查询
// query string { __type(name: "PostType") { name fields { name, type { name, kind } } } } // response result { "data": { "__type": { "name": "PostType", "fields": [ { "name": "id", "type": { "name": null, "kind": "NON_NULL" } }, { "name": "name", "type": { "name": null, "kind": "NON_NULL" } }, { "name": "createDate", "type": { "name": null, "kind": "NON_NULL" } }, { "name": "title", "type": { "name": null, "kind": "NON_NULL" } }, { "name": "subtitle", "type": { "name": "String", "kind": "SCALAR" } }, { "name": "content", "type": { "name": "String", "kind": "SCALAR" } }, { "name": "tags", "type": { "name": null, "kind": "LIST" } } ] } } }最后
总结一下,GraphQL 是一种客户端同服务端之间数据交互的概念,具有强大、灵活、易扩展等的特点。既然,它是一种概念,那么,不同的语言就可以有各种不同的实现方式。
概念并不多,在于灵活运用。
PS:再次强调,本文主要讲的是 GraphQL 的核心概念,Type System 中所定义的类,都是设计类,并不是具体实现代码。实现请听下回分解。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/90821.html
摘要:系列文章核心概念浅尝本文常言道,实践是检验真理的唯一标准。遵循传统,第一个例子必须是。官方提供这个中间件来支持基于的查询,所以,这里选用作为服务器。首先是,这里对做了一点小修改,给几个字段添加了不能为空的设计。 系列文章: GraphQL 核心概念 graphql-js 浅尝(本文) 常言道,实践是检验真理的唯一标准。 上一篇文章讲了 GraphQL 的核心概念,所提到的一些例...
摘要:我在工程实践中直接使用类作为对应实体类的。因此我的结论是,此库并不适用于我的工程实践。工程实践中对其应用方式的考虑在的官方教程中建议针对每请求创建新的实例,查询请求结束则实例们的生命周期结束。 因为自己写过基于react的前端应用,因此一看到GraphQL就被深深吸引,真是直击痛点啊!服务端开发一直是基于java, Spring的,因此开始研究如何在现有工程框架下加入graphql的支...
摘要:我们知道是一种从服务器公开数据的流行方式。描述所有的可能类型系统基于类型和字段的方式进行组织,而非入口端点。因此,需要对后端进行调整,以满足新的数据需求,这会降低生产力并显著降低将用户反馈集成到产品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前几天的《StateOf...
摘要:我们知道是一种从服务器公开数据的流行方式。描述所有的可能类型系统基于类型和字段的方式进行组织,而非入口端点。因此,需要对后端进行调整,以满足新的数据需求,这会降低生产力并显著降低将用户反馈集成到产品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前几天的《StateOf...
摘要:我们知道是一种从服务器公开数据的流行方式。描述所有的可能类型系统基于类型和字段的方式进行组织,而非入口端点。因此,需要对后端进行调整,以满足新的数据需求,这会降低生产力并显著降低将用户反馈集成到产品中的能力。 showImg(https://segmentfault.com/img/remote/1460000017875905?w=2234&h=974); 在前几天的《StateOf...
阅读 2608·2021-11-22 15:25
阅读 1429·2021-11-15 17:59
阅读 1129·2021-09-29 09:34
阅读 1534·2021-09-26 09:46
阅读 3029·2021-09-02 15:40
阅读 1190·2019-08-30 15:56
阅读 3281·2019-08-30 15:55
阅读 693·2019-08-29 17:08