graphql

纯rest：一个endpoint对应一个资源
优点：灵活、解构
缺点：由于一个endpoint对应一个资源所以需要很多次请求

类rest：一个endpoint对应一个视图
优点：一次请求、所得即所需
缺点：不够灵活、高度耦合、很高的维护成本、迭代慢

What

GraphQL 是由 Facebook 创造的用于描述复杂数据模型的一种查询语言。这里查询语言所指的并不是常规意义上的类似 sql 语句的查询语言，而是一种用于前后端数据查询方式的规范。

GraphQL 既是一种用于 API 的查询语言也是一个满足你数据查询的运行时。 GraphQL 对你的 API 中的数据提供了一套易于理解的完整描述，使得客户端能够准确地获得它需要的数据，而且没有任何冗余，也让 API 更容易地随着时间推移而演进，还能用于构建强大的开发者工具。

why

Graphql VS Restfull

image.png

Rest与Graphql对比实例

应用场景一：先订购披萨，然后再超市购物，接着再打电话给干洗店上门取衣服。三个店铺，三个电话。而graphql就像一个私人助理。只需要给出三个地方的地址，然后告诉Ta你想要什么（“衣服要干洗，一个大比萨饼，两大鸡蛋”），然手就可以坐等结果了

应用场景二：在博客应用中，应用需要展示指定用户的帖子标题。同一页面里还会显示该用户的最新3个关注者的名字。
REST和GraphQL是如何解决这个业务的呢？

使用rest API

通常可以调用多个接口获取数据。这对上述场景，首先可以调用/user/:id 接口来获取用户数据。紧接着，调用/users/<id>/posts返回该用户的所有帖子。最后，第三个接口可以是/users/<id>/followers，返回该用户的关注者列表。

graphql请求方式

核心概念

这篇文章主要分享的是 GraphQL 的核心概念，主要分为：Type System（类型系统）, Query Language（查询语言）, static Validation（静态验证）和 type Introspection（类型检查）四部分
（更多Schema和类型，请查看官网http://graphql.org）

GraphiQL 是用于查询 GraphQL 端点的非常方便的浏览器端 IDE。

Type System

类型系统是整个Graphql的核心，它用来定义每个查询对象和返回对象的类型，将所有定义的对象组合
起来就形成了一整个Graphql Shema
还是以博客系统的例子来说明：我们首先建立一个文章的类型

type Post {
     id: String,
     name: String, 
    createDate: String, 
    title: String, 
    subtitle: String, 
    content: 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 这几个特殊类型。
再修改一下之前的文章类型，使一个文章可以包含多个标签。
文章类型就定义好了，包含了一系列的字段，字段的类型正好都是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 这几个特殊类型。
再修改一下之前的文章类型，使一个文章可以包含多个标签。

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，
    post: [Post]
 }

最后，根据整个博客网站的需求，组合嵌套刚刚定义的文章类型和标签类型，建立一个根类型作为查询的schema。

type Blog { 
    post: Post, // 查询一篇文章 
    posts: [Post], // 用于博客首页，查询一组文章
    tag: Tag, // 查询一个标签 
    tags: [Tag], // 用于博客标签页，查询所有标签
 }

Ok！我们的类型和schema都定义好了，就可以开始查询了，怎么查呢，接下来我们看一下Graphql 的查询语法

QUERY Language(查询语言)

GraphQL 的查询语法同我们现在所使用的有一大不同是，传输的数据结构并不是 JSON 对象，而是一个字符串，这个字符串描述了客户端希望服务端返回数据的具体结构。

知道了概念，那么一个 GraphQL 的查询到底长什么样哪？继续我们的例子，假设，我们现在要查询一篇文章，那么，GraphQL 的查询语句就可以是这样。

query RootQuery { 
    blog {
            posts {
                id,
                name,
                createDate,
                title,
                subtitle,
                content
          }
    }
}

返回结果：

返回的结果是和之前的一样。查询关键字只有在多个查询时才必须，在单个查询时可以省略。同时，也可以对查询的返回起别名，再来看看看博客的首页希望展示一个粗略的文章列表，那么这样的一个查询语句可以是：

query FetchPostQuery {   
    blog {    
    postList: posts {        
        id,        
        name,       
        createDate,       
        title,       
        subtitle,       
        tags {            
            name,            
            label        
        }    
    }  
      }
}

返回的结果：

从中我们可以看到，数据返回了整个文章的属性以及部分的标签属性。其中，标签属性并没有返回全部的字段，而是只返回了 name 和 label 字段的属性，做到了返回数据的结构完成同请求数据的结构相同，没有冗余的数据。
查询添加参数的需求也非常基本，在 GraphQL 的查询语法中也相当简单，就拿刚刚的例子，要查询特定的文章就可以把它改成这样。

Query RootQuery {   
     blog {     
    post(name: "graphql-core-concepts") { 
            id,        
        name,        
        createDate,       
        title,        
        subtitle,        
        content,       
     tags {            
        name,           
        label        
    }   
     } 
 }

返回的结果：

STATIC VALIDATION

由于 GraphQL 是一个强类型语言，所以它可以在执行查询之前检查每个查询语句是否满足事先设定的 schema，符合则合法，如果查询语句不合法则不进行查询。
以上所举的都是合法的例子，官网上举了一些例子，这里就不贴了，我们就总结看看要注意的有哪几点。

fragment 不能引用自己从而形成一个循环
不能查询类型中不存在的字段
查询的字段如果不是 scalar type(标量类型)或 enum type（枚举类型），则需要明确该字段下所包含的字段
同上一条相对，如果查询字段是 scalar type(标量类型)，那么它就不能再有子字段

TYPE INTROSPECTION

在Graphql中Introspection是一个非常有用的功能，它可以用来查询当前Graphql的schema，从而得
知服务器端支持何种类型的查询。
这是一个非常强大且有用的功能，现在公司的开发基本是前后端分离的，客户端并不知道服务端提供的
Schema结构，但可以通过查询__schema字段来获得当前所支持的查询类型。

query RootQuery {  
     __schema {    
        types {     
             name   
         }  
    }
}

返回的结果：

从返回的数据中可以看到，我们自定义的BlogType，PostType和TagType，剩下的都是Graphql内部类
型，其中又分为两类：一类是ID，String和Boolean所表示的标量类型，另一类以双下划线开头的是用于
自我检查的类型。

知道了自定义了，假设，还想知道自定义类中包含那些属性以及属性的类型，就可以这样查询：

query RootQuery {   
    __type(name: "PostType") {   
    name    
    fields {      
        name   
        type {        
            name        
            kind 
            }    
    }  
     }
}

返回的结果：

graphql初探

graphql初探

graphql

What

why

Rest与Graphql对比实例

使用rest API

graphql请求方式

核心概念

Type System

QUERY Language(查询语言)

STATIC VALIDATION

TYPE INTROSPECTION

推荐阅读更多精彩内容