GraphQL 浅谈，从理解 Graph 开始

Posted 2021-04-30 大转转FE

前言

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)，类似于持续演进(相互借鉴)的 Flow和 TypeScript，用来描述你的数据，先看官网的例子(细节再议)

 
   
   
 

  
    
    
  
项目的type
  
    
    
  
type Project {
  
    
    
  
  name: String
  
    
    
  
  tagline: String
  
    
    
  
  contributors: [User] // 数组表示多个，type 为下面的 User
  
    
    
  
}
  
    
    
  
type User {
  
    
    
  
  name: String
  
    
    
  
  photo: String,
  
    
    
  
  friends: [User] // User 的朋友们， type 还是 User
  
    
    
  
}
 
   
   
 

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

 
   
   
 

  
    
    
  
请求你所要的数据 // 基于 Queries
  
    
    
  
{ // 查找 name 为 GraphQL 的 project
  
    
    
  
  project(name: "GraphQL") {
  
    
    
  
    tagline
  
    
    
  
  }
  
    
    
  
}
  
    
    
  
得到可预测的结果
  
    
    
  
{ // 返回 json
  
    
    
  
  "project": {
  
    
    
  
    "tagline": "A query language for APIs"
  
    
    
  
  }
  
    
    
  
}
 
   
   
 

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

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

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

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

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

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

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

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

我的观点：当技术栈的缺点因其演进不再明显之时，必是它优点大放光彩之日