关于graphql:GraphQL-概念入门

Restful is Great! But GraphQL is Better. — My Humble Opinion.

GraphQL will do to REST what JSON did to XML. — Samer Buna from Quora

GraphQL 作为 Facebook 的前端三架马车之一（另外两架是 Relay 和 React, 三者能够无缝联合），提出也有一段时间了，但真正用过的人却出奇的少，
截止到 2018 年底，依据 Stateofjs 的数据看，
尽管只有 1/5 的开发人员用过，但却有高达 62.5% 的人示意听过并想试试😂 果然咸鱼才是支流呀；
接下来我会就 GraphQL 的前后端利用出个系列文章介绍 GraphQL 及其应用感触，顺便填坑。

本系列将以 Python + Django + Graphene 作为后端服务端。Apollo 作为前端客户端。

官网是这么说的：

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查问的运行时。
GraphQL 对你的 API 中的数据提供了一套易于了解的残缺形容，使得客户端可能精确地取得它须要的数据，而且没有任何冗余，
也让 API 更容易地随着时间推移而演进，还能用于构建弱小的开发者工具。

我总结一下：

首先 GraphQL 它是一种跟 Restful 规范相似的查询语言。它们的性能层级相似（如下图），但从理论利用、理念上说的话，它们是齐全不一样的两种状态。

Restful 主张的是“所有数据皆视为资源”，
在现实状况下：不同的申请内容对应着一个惟一的 ID. 不同的数据动作对应到不同的 HTTP 办法上。

GraphQL 主张的是“所有数据皆视为数据（树状的）”，
不同的申请内容都会对应到同一个 HTTP 地址，也会对应到同一个 HTTP 办法（POST）。
不同的动作由操作符决定。它的总体体验会更像是一个 SQL Shell, 你须要什么就申请什么，你不须要的内容它也不会硬塞给你。

与 Restful 相似，他们都只是个规范，不同产品它们的具体实现也是有所出入的，没有齐全实现所有个性也是失常的。
但次要的性能及个性是在所有实现中都有的。另外两者的不同语言反对根本差不多，常见语言都能有对应的实现。

上面我会就两者的差别进行绝对具体的比拟，
因为 Restful 算是个比拟通用的规范了，上面我不会具体介绍 Restful 的具体内容，
如果你不相熟 Restful 规范的话最好先理解一下后再持续，以便更好地了解。

Restful 主张所有数据皆视为资源，这意味着不同的数据你会须要屡次申请，
比方一个像我这样的 SPA 类型的集体博客，你大略会在进入主页时申请这些内容（纯假如，非理论状况）：

// 一些配置类信息：比方配置项、站点题目等
https://example.com/config/

// 侧边的标签栏
https://example.com/tags/

// 侧边的归档栏
https://example.com/archives/

// 布告信息栏
https://example.com/billboard/

// 文章的列表
https://example.com/articles/

像这样一个单页博客一进主页时必然要申请的信息就要这么多，设想一下如果是一个高并发的、内容结构复杂的网站那申请数量会有多大。

但这些在 GraphQL 中的话，你只须要申请一次，比方：

query {
  config: {
    key,
    value,
  }

  tags: {name,}

  archives: {name,}

  billboard

  articles {
    id,
    name,
    description,
    tags: {name,},
  }
}

而后，接口的返回内容会相似这样：

data: {
  config: [
    {
      key: 'title',
      value: 'xxx',
    },
    {
      key: 'slogan',
      value: 'xxx',
    },
  ],

  tags: ['Go', 'Java', 'Javascript'],

  archives: ['2011', '2012', '2013'],

  billboard: 'XXX XXX XXX',

  articles: [
    {
      id: 1,
      name: 'some name',
      description: 'XX XX XXX',
      tags: ['tag1', 'tag2'],
    },
    {
      id: 2,
      name: 'some name',
      description: 'XX XX XXX',
      tags: ['tag1', 'tag2'],
    },
    {
      id: 3,
      name: 'some name',
      description: 'XX XX XXX',
      tags: ['tag1', 'tag2'],
    },
  ],
}

能够看到接口的返回内容是一个依照你所申请的内容及字段精确返回的一个 JSON 数据。
并保留着你申请的构造体，你须要一个长成什么样的树状构造齐全能够由你本人结构，
后端也不必为你的每个特定的需要去写一些奇奇怪怪的接口以填补业务与开发之间的实现抵触。

再有一个就是在某些情景下，以 Restful 的形式申请的话会须要将申请离开，即原本能够并行申请的事件因为 Restful 规范而须要改为串行的。

比如说咱们要获取以后这篇文章所关联的分类下的其余相似文章，而后在边上显示。

你可能会先申请：

https://example.com/article/1/

失去对应的文章分类后，再申请：

https://example.com/article/?category=graphql&is_recommend=true

而后你才能够渲染残缺的页面内容。这些在 GraphQL 中都是能够防止的。

对于数据间的关联性，一般的 SQL 外键及关联关系它也都能间接映射成子项返回，
比方下面的例子一中 articles 外面的 tags 个别就是以数据外键的形式连贯到不同的表中的，在 GraphQL 中它能以子树的形式间接取用。

所有的查问操作在 GraphQL 中以操作符 query 执行。外面能够写有数多个不同的申请内容，不必离开申请屡次。
在你须要对同一个内容申请屡次的状况下，目前前端 GraphQL 客户端都有主动缓存解决，
能够做到以后网页实例只对某一个内容申请一次后前面再次申请该内容时不会再收回网络申请而间接应用缓存信息，当然你要再次收回也是能够做到的。

在 Restful 中，咱们习惯用不同的 HTTP 办法形容行为，但在 GraphQL 中，咱们用操作符批示行为。

下面的 query 指代的是查问操作，绝对应于 SQL 中的 select 操作。那如果要批改呢？
在 GraphQL 中咱们用 mutation, 对应到 SQL 中是 update, insert 及 delete. 乍看之下有种乱了的感觉，但理论应用时并不会有这种感觉。
尽管这部分我切实是吹不起来，因为这部分我集体会感觉它更像是将原本在后端做的内容放到了前端。它的应用形式十分像是给了前端一个“后端函数”。

* 上面所有例子只是演示，并不是理论写法，理论写法会更谨严

如果咱们要删除一篇文章，能够这样：

mutation {deleteArticle(id: "some ID") {}}

如果要新增一篇文章：

mutation {
  createArticle(
    title: "some title",
    content: "some content",
  ) {
    id,
    title,
    content,
  }
}

批改操作与新增相似，不再赘述。

尽管看起来绝对稠密了点，如同很随便的感觉，但其实这些操作是给了开发者更大的自由度。不便订制行为。
另外有一点值得一吹的，在真正做 Mutation 前，调用了一个 Mutation 操作后，它会在前端代码外面主动做传入的参数类型校验，
相似动态语言的编译，如果传入参数有错会主动报错并提醒出错地位给出错误信息，如果没问题才会收回 HTTP 申请变更操作。
传到后端时会由后端再次做校验。这点我集体相当喜爱。

订阅算是个比较突出的个性，传统业务上也经常会有相似的需要，但 Restful 并没有管到。
在 GraphQL 中订阅这个性能目前在大部分实现中如同是不齐全反对的。
其大体意思就是当你在前端中对某个内容进行订阅后，当后端的这个内容有变更时会由服务端被动告诉前端，进而引发 UI 逻辑或操作等。
目前这部分个性如同大部分实现是没有反对或者没有齐全反对的。而且如同大部分情景下只能是依赖长链接或轮询去做。
尽管如此，它还是十分让人期待的，因为它所做的是让你能够对任意数据进行订阅而不是像传统的实现那样让后端独自为某个非凡内容做个专用接口。

一个经典利用场景比方：
当你在关上一篇文章时，对此文章的评论区收回一个订阅操作，此时如果有人在你看文章的同时对文章新增了评论或回复评论之类的，
对应的变动会由后端被动推送给前端，这样就能够实时地看到最新的评论内容了。

订阅在 GraphQL 中对应 subscription 操作符。与 mutation 写法相似。

如果有人比拟理解还请不吝赐教，我对这块不太熟悉也没深刻理解。

传统的 Restful 采纳间距式分页，即定好一个固定的间距后，能够由此间距大小及以后所在页码去推算任意页的内容。

GraphQL 绝对更推崇指针式分页，即不论你以后在哪一元素上，都以以后所在这个点为指针，往前或往后申请给定数量。
它的一个劣势是无奈像间距式一样在以后地位推算出任意页的内容，但它的劣势在于你齐全不必关怀任何其余信息，
永远只把以后点作为指针即可任意向前或向后地无缝伸缩。

Restful 这样的形式会更合乎传统桌面端索引式的交互体验习惯。
而 GraphQL 这样的形式则在更古代的 web 交互中，比方瀑布流、小程序及原生利用中的下滑主动加载更多这样的情景中更为不便。

PS: GraphQL 中也能够兼容间距式分页，具体实现形式之后会讲，在这篇文章中不细说。

在 Restful 中规范治理形式是以不同的链接入口申明的，如：

https://v1.example.com/
https://example.com/v1/

在 GraphQL 的世界中并不存在不同的入口之分，接口版本迭代能够无缝适度，因为自身不同的查问内容就是由前端收回的，前端并不会受到后端限度。

像我下面说的，在理论应用时，前后端都会有强类型的参数校验，所以相对而言是更容易感知谬误的，并且！它极大地缩小了其余隐性出错的可能。
比如说像后端改了某个接口中的货色忘了告知前端进而导致的逻辑谬误。这些极其容易产生的问题在 GraphQL 中都不太可能呈现。

如我在下面【查问】一节中提到的，GraphQL 的客户端自带了缓存零碎，能够更进一步节俭申请耗费，不想要此个性也能够关掉。

像下面提到的，你须要什么内容能够由前端决定。在须要强关联性的业务中，
GraphQL 能够有限查找关联关系，在前端就能够省掉大量的异步语法、极大防止了 Promise 或 Callback 天堂的问题。
除此以外，在一些后端语言中，比方 Python 字段通常约定为下划线命名。
但在 Javascript 中，更为罕用的是驼峰命名法，因为数据是由后端返回的，防止不了的就让前端的代码变得奇丑无比夹杂着各种不同的命名形式；
兴许你会说，咱们能够在拿到数据后进行数据命名荡涤，但这无疑会增大工夫复杂度同时升高了代码的可保护水平，无论怎么说都不太可取。
但！这个问题在 GraphQL 中（谨严地说是在我所用的这个技术栈中）并不存在。
因为在 Graphene 中它会对返回数据主动进行命名形式转换，前端用驼峰，后端用下划线与不烦扰。

因为 GraphQL 的输入输出都是基于 Schema 定义的，调用办法及查问都是强类型输入输出，能更高效地定位谬误起因及地位。
如果是客户端操作传的参数不对，它甚至不会发出请求间接就在客户端报错并阐明起因。
如果是正确传参但服务端出错了，则在同一个查问中其余内容都能正确返回，只有出错的内容会为空并会提供一个 message 字段阐明出错起因及地位。

下图为 Github 的 GraphQL v4 API，
能够看到用户查问出错了但 search 的数据失常返回。

除了下面十分具体的报错外，你甚至能够间接在浏览器中进行动静 Debug;
下图是我本人的一个我的项目的 Debug 查问，能够查看以后查问的 SQL 语句是怎么写的、用了多久工夫、是否用时过久、
带了什么参数、事务 ID、事务状态等各种各样的信息。

（因为平安起因就不展现具体 SQL 语句了）

由下面的图片能够看到其实应用 GraphQL 的时候它会提供一个网页内的动静交互窗口，提供 GraphQL 的主动补全、格式化查问语句、历史操作等信息。
其中最最最弱小的就是它的接口文档了。代码即文档式的信息十分有用。

在这里你能够间接看到整个树状构造是怎么的，也能够看到清晰的类继承关系（图没截到），也能够看到不同查问内容的具体阐明及参数类型等内容。

无论什么货色，两物相较必有优有劣。对于开发一个现代化的、简单的 web 服务或者站点而言，GraphQL 有着一堆的长处，但它也有显著的劣势。

因为 GraphQL 自带层级查问，所以容易呈现多余的查问，引起不必要的查问开销。

当然这个问题很大水平上也和你应用的后端框架有关系，对于 Django 的我在此举荐一篇写得很不错的文章：
N+1 问题

尽管它有提供一个性能非常弱小的网页内调试窗口。然而在理论开发中时，前端在 IDE 中写各种语句时是不会有任何提醒的，也容易写错拼错，
因为编辑器基本不能辨认你写的是什么内容，它最多把它当成纯文本，也不会格式化内容，所以在开发上在这点上会有点不太难受。

Restful 因为历史悠久普用性也大，所以基本上市面上所有的接口工具都能反对 Restful 查问，但 GraphQL 却不行。
目前我晓得的只有 Insomnia 反对，但不能很好反对文档局部性能。（当然框架自身曾经提供了超棒的调试工具了）

这个只看你功底了，市面上目前差不多是两家独大的状况，一个是 Facebook 自家的 Relay，另外一个是由社区反对的 Apollo.

Relay 学习老本会更高些，就相似你刚学完 React 的基本知识，会用 React 写一些简略页面了，
忽然被要求去学习 Redux 理念差不多。须要学习一套新的数据管理形式。

相较而言 Apollo 会更敌对一些，反对 JSX 式的块状写法，也反对间接当成 Axios 那样只用它的申请性能，也能够兼容 Relay 式的查问写法，学习门槛绝对低了不少。
自带的本地状态治理能够完完全全代替掉 Redux. 真 · 一个顶俩（Axios + Redux）

两者同为规范、设计指南；并不能主观地说谁就肯定比谁好。但就我集体而言我能看到 GraphQL 绝对 Restful 的相当多劣势。
毕竟 GraphQL 自身年纪就比 Restful 小，他的呈现必然是为了解决前代的遗留问题，不是全副也是大部分。

最重要的是两者是能够齐全兼容的。谁也不烦扰到谁。

最初丢多点拓展浏览及学习链接：

GraphQL – 中武官网
How to GraphQL – 一个学习网站
Rest VS GraphQL
GraphQL or REST
Is GraphQL a REST killer?

关于graphql:GraphQL-概念入门

GraphQL 概念入门

1. 什么是 GraphQL

2. GraphQL 与 Restful 的数据操作比照

2.1 查问

2.2 变更

2.3 订阅

2.4 分页

3. GraphQL 绝对 Restful 的劣势

3.1 接口版本治理

3.2 更清晰通明的数据结构及更强壮的接口

3.3 更好的缓存零碎

3.4 前端敌对的开发体验

3.5 谨严的开发体验及更显著的报错机制

3.5 更不便的调试流程

3.6 代码即文档

4. GraphQL 的劣势

4.1 性能开销

4.2 无提醒开发

4.3 接口测试工具绝对少

5. GraphQL 客户端哪家强

6. 完结