54

GraphQL 浅谈,从理解 Graph 开始

 6 years ago
source link: http://mp.weixin.qq.com/s/Jfcj70Cz6fE2AX67lqzL0g
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

GraphQL 浅谈,从理解 Graph 开始

Original 章辰 大转转FE 2017-12-29 01:10 Posted on

GraphQL is a data query language developed internally by Facebook in 2012 before being publicly released in 2015. It provides an alternative to RESTful architectures. —— from wikipedia.

GraphQL 是 Facebook 于 2012 年在内部开发的数据查询语言,在 2015 年开源,旨在提供 RESTful 架构体系的替代方案。

掘金翻译计划在今年 10 月上线了 GraphQL 中文官网,最近它的讨论和分享逐渐增多。其实阿里内不少业务线早有尝试和分享,听闻基于 GraphQL 再造了个 TQL。也在其开源的 Node.js企业级框架 egg中,发布了对应的 plugin。感觉这是一个让广大(前端)开发者(重新)认识学习 GraphQL的好机会,就让我们来回顾一下它~

参考链接微信访问不了,可以阅读原文(顺手关注下转转FE的 Github 噢)~

从 Graph 字面开始

先看官网的解释~

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。

总结的稍显高深,简单拆解一下:

SQL (Structured Query Language) 是结构化查询语言的简称。所以 Graph+ QL = 图表化(可视化)查询语言,是一种描述客户端如何向服务端请求数据的 API语法,类似于 RESTful API 规范。

注:不要联想到 MySQL、NoSQL,它不是图形数据库,比如 Neo4j。 GraphQL 有配套的数据库服务, graphcool 可以部署在 Docker 上或运行在基于 BaaS(Backend as a Service) 的 Graphcool Cloud。但它不依赖任何数据库,且能和任何后端(SQL、MongoDB、Redis 等)一起使用,也可以包裹在 RESTful API 之上。

GraphQL 的特性

它定义了一套类型系统( TypeSystem),类似于持续演进(相互借鉴)的 FlowTypeScript,用来描述你的数据,先看官网的例子(细节再议)



  1. 项目的type

  2. type Project {

  3.  name: String

  4.  tagline: String

  5.  contributors: [User] // 数组表示多个,type 为下面的 User

  6. }

  7. type User {

  8.  name: String

  9.  photo: String,

  10.  friends: [User] // User 的朋友们, type 还是 User

  11. }

接下来你可以把 GraphQL查询语言( Queries)当成是没有值只有属性的对象,返回的结果就是有对应值的对象,也就是标准的 JSON



  1. 请求你所要的数据 // 基于 Queries

  2. { // 查找 name 为 GraphQL 的 project

  3.  project(name: "GraphQL") {

  4.    tagline

  5.  }

  6. }

  7. 得到可预测的结果

  8. { // 返回 json

  9.  "project": {

  10.    "tagline": "A query language for APIs"

  11.  }

  12. }

虽然 project 在类型系统里定义了三个字段,但我们(客户端)只需要 tagline 这个字段,服务端就只返回这个字段,而 contributors 里的 User 和其对应字段,本次查询( Query)并不关心。这个 demo 看似简单,其实带来了很多特性~

  • 强类型: GraphQL与 C 和 Java 等后端语言相得益彰,服务端能对响应的形状和性质做出一定保证,而 RESTful是弱类型的,缺少机器可读的元数据;

  • 分工: GraphQL让服务端定义好支持哪些 Queries,把对数据的 Query需求下放到客户端管理,分工明确的同时保持对 API 的聚焦;

  • 分层: GraphQL的 Query本身是一组分层的字段,查询就像返回的数据一样,是一种产品(工程师)描述数据和需求的自然方式;(PS:部分翻译的,国外好像都把产品叫做 Product Engineers 而不是 Product Manager。感觉在吐槽的样子)

  • 预测性: GraphQL的 Query只返回客户端要求的内容,没有任何冗余(不浪费流量),而且它只有一个接口地址,由此衍生了另一个特性;

  • 兼容性:需求变动带来的新增字段不影响老客户端,服务端再也不需要版本号了,极大简化了兼容问题;(App 通常是 1-2 周的固定周期发版,在原生应用不强制升级的世界里,会出现用户 1-2 年都不升级的情况。 这意味可能同时有 52 个版本的客户端查询我们的服务端,而在 Fackbook 中 GraphQL API 曾支持了横跨 3 年的移动端)

  • 自检性: GraphQL能在执行 Query之前(即在开发时)提供描述性错误消息,在给定查询的情况下,工具可以确保其句法是正确有效的,这使得构建高质量的客户端变得更加容易;

  • Doc & Mock: GraphQL的文档永远和代码同步,开发无需维护散落多处的文档,调用者也无需担心过期问题,而且基于类型系统的强力支撑和 graphql-tools,mocking 会变得无比容易。

GraphQL通过它的特性解决了不少问题,当然它不是没缺点的,这个下期再聊~

我的观点:当技术栈的缺点因其演进不再明显之时,必是它优点大放光彩之日😊。与此同时 GraphQL伴随着 graph 又带来了很多新的思考~

GraphQL 的延伸,graphical & graph(s)

图像天然更生动形象易于理解,这意味着 GraphQL交互极强的工具和生态,比如:

  • graphiql —— A graphical interactive in-browser GraphQL IDE. 一个让我们在浏览器里用图形交互的方式探索及书写 GraphQL的 IDE。

  • graphql-voyager —— Represent any GraphQL API as an interactive graph. It's time to finally see the graph behind GraphQL! 用交互式图表展示任意的 GraphQL API,总算能看见 GraphQL背后的 graph 了!

Image

今年 5 月 22 日 GitHub 发文宣布,去年推出的 GitHub GraphQL API 已经正式可用 (production-ready),并推荐集成商在 GitHub App 中使用最新版本的GraphQL API V4。我们可以用 graphql-voyager 探索(但因 Types、Queries、Mutations 较多数据加载略慢)。

后一个工具可把笔者惊艳坏了,想了解它的生态可以在 awesome-graphql 里寻找。通过它们,所有人都能快速阅读查询文档,调试我们的查询。

PS:主要是方便调用者和团队新人的,不过可以思考一个问题,每天是写代码还是看代码多?看接口文档呢?

另一种思维模式 —— Thinking in graphs

图是将很多真实世界现象变成模型的强大工具,因为它们和我们天然的心理模型和基本过程的口头描述很相似。大家应该都没忘在学校做的数据库设计,笔者简单回顾下当年手绘 E-R 图的过程😢

  • 一个班级有一个班主任, 1:1的关系;

  • 一个班级有多学生多个教师, 1:n的关系;

  • 每个学生可以上不同的课程, n:m的关系。

OK,然后大概就成了下面这个样子,原谅我从百度找的图:

Image

E-R 图也称实体-联系图(Entity Relationship Diagram),提供了表示实体类型、属性和联系的方法,用来描述现实世界的概念模型。

  • 真实世界的数据在本质上是分层的:今天大多数的产品开发涉及视图层次的创建和操作,这与应用程序的结构保持一致;

  • 我们的开发模式本身也是产品需求驱动的,客户端关注需求(怎么取、取哪些),服务端关注能力(可用性、性能),这样的协作模式更现代更高效;

  • 数据和实体背后的本质也是关系图:我们的服务端用对象和关系的形式处理,只不过在数据库用扁平的表格存储它们;(以前你可以将负责的业务数据通过导出 E-R 图展现给同事和老板。如今你还可以通过 GraphQL把到对外暴露的 API也建模成一张图。)

  • GraphQL沉淀出来的数据模型Schema)也可以作为一种给你的团队(后端前端客户端甚至产品)及第三方沟通的共同语言,让大家对这些业务领域的规则形成共同的理解,最终达成共识。

GraphQL的原理、和 RESTful的优劣对比以及最佳实践等等,未完再续~

参考资料 —— 需要翻墙

来自官方的介绍:GraphQL Introduction

GraphQL: A data query language

来自 InfoQ 的采访:Facebook开源数据查询语言GraphQL

来自官方的 Talks:GraphQL: Designing a Data Language

30分钟内现场演示用Python、Ruby、Nodejs.js,设计3次 GraphQL Sever:Zero to GraphQL in 30 Minutes

欢迎评论交流~

如果对您有所帮助,可以转发到朋友圈加速 GraphQL 的传播吖~


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK