GraphQL(一):GraphQL介绍

GraphQL是什么

GraphQL是facebook开源的一套数据交互方案,它并非某种具体的语言或者框架,它只是提供了一套解决方案,这套解决方案通过GraphQL规范进行定义,不同语言可以有自己的GraphQL实现,目前已经有很多语言完成了GraphQL的实现,可以在这里查看。

怎么使用GraphQL

GraphQL致力于提供一种直观的弹性语法系统,用以描述客户端程序设计时的数据需求以及数据交互行为。通俗地讲就是允许客户端在请求中精确的定义自己需要什么,服务端根据客户端的请求精确的返回相应的内容。比如有如下两个相互关联的实体:

Teacher{
    name: String
    phone: String
    age: Int
}

School{
    id: String
    name: String
    address: String
    teachers: List<Teacher>
}

使用GraphQL查询指定学校的名称是这样的:

school(schoolId: "schoolId1"){
    name
}

返回:

data{
    "name" : "北京大学"
}

如果想要查询学校的名称以及所有老师的名字和电话:

school(schoolId: "schoolId1"){
    name
    teachers{
        name
        phone
    }
}

将得到:

data{
    "name" : "北京大学"
    "teachers" : [
        {
            "name" : "李老师",
            "phone" : "13312345678"
        },
        {
            "name" : "张老师",
            "phone" : "13312345673"
        },
        {
            "name" : "王老师",
            "phone" : "13312345672"
        }
    ]
}

以上只演示了GraphQL提供的查询(query)功能,GraphQL还支持修改(mutation)和订阅(subscription)。

要使得客户端可以使用GraphQL的方式请求数据,首先需要在服务端提供GraphQL服务,这里可以查看现有的实现了GraphQL的平台,关于如何搭建GraphQL的服务,请查看GraphQL(二):GraphQL服务搭建

同时,GraphQL提供了强大的开发者工具GraphiQL,可以实时查看数据模型和API,为前后端开发者提供了一个便捷的沟通平台。

为什么要使用GraphQL

通过上面的内容,大致可以了解GraphQL给前后端数据交互带来的变化。
使用RESTful风格的API,会从指定接口加载数据。每个接口都明确定义了返回的数据结构。这意味着客户端需要的数据,已经在URL中制定好了。GraphQL中采用的方式截然不同,GraphQL的API通常只暴露一个接口,而不是返回固定数据结构的多个接口。 GraphQL返回的数据结构不是一成不变的,而是灵活的,让客户端来决定真正需要的是什么数据。

这样的变化能够在一定程度上解决使用RESTful风格接口完成数据交互时会遇到的问题:

  1. 多端点,每个API都有自己的路径需要管理


    image
  2. API数量庞大,新人自学习困难
    GraphQL通过图的方式来组织模型,结合GraphiQL,新人能够快速上手
  3. 后端数据模型难以规范
    RESTful接口多为页面驱动,后端可能会设计很多差别不大的模型,目前并没有一种强约束去要求后端开发人员规范模型,GraphQL要求在一开始就完成业务模型的分析和定义,避免后面业务模型的泛滥
  4. 在API设计时往往是面向页面的,而页面相比模型具有更差的稳定性
  5. API文档维护工作量大
    RESTful的API需要管理大量文档,但是依然存在文档更新、文档查阅方便的问题,虽然可以动用人力完善工具去解决,但是GraphQL天然就自带文档工具特性。我们在定义字段时,一并写上description,通过GraphiQL可以实时查看:
type School {
    id: ID!
    # 学校id
    schoolId: String
    # 学校名称
    schoolName: String
    # 学校年龄
    schoolAge: Int
    # 学校地址
    schoolAddress: String
    # 学校包含的老师
    teachers: [Teacher]
    # 校长
    master: String
}

GraphiQL中查看:


image
  1. 数据聚合较为麻烦
    这是在后端经常需要处理的问题,比如,客户端需要一些数据,我们定义了一个RESTful的接口,但是这些数据分别在A和B服务中,最终我们会在后台手动聚合A和B的数据到一个模型里返回。而GraphQL通过不同的Resolver天然完成了数据聚合功能

GraphQL解除了接口和数据之间的绑定,对业务数据模型做了抽象和整理,以图的方式来明确模型之间的关系,通过这些关系,具体业务场景可以定制自己的数据,不同的业务场景只要基于同样一套基础数据模型就可以复用过往的接口。

以上好处讲起来有些抽象,需要多多实践多多体会。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270