GraphQL入门 - Githubissues

GraphQL不仅用于前端的react、vue，在node、java、go生态中也可以实现，它是一门API查询语言。
相对拖泥带水的REST，GraphQL按需取数据。
GraphQL解决了什么痛点？引用V友TommyLemon的一段很精彩的评论。

说明很多公司都前后端分离后碰到了各种恼人的开发与沟通问题

1.浪费性能、流量和带宽返回不需要的字段、对象等

2.各种奇葩的缩写、混乱的命名各种缩写、拼音、驼峰和非驼峰混用等，只有看文档才知道是什么、才知道用哪个，而且文档还很可能有错误。例如评论数量可能是 commentCount, comment_count, cmt_count, pl_num... 分页页码可能是 page, pageNum, page_number, page_num, pnum...

3.数据类型不稳定或随意改变对象为空时应该返回 null 或 {} ，但实际会返回空数组 []，甚至是 "", "[]" 等，导致前端解析崩溃；后端擅自改变类型导致线上 App 崩溃...

4.几百甚至上千个混乱的状态码各项目几乎完全不通用，不看相关的内部文档根本不知道对应的错误是什么，而且文档还很可能有错误。例如注册: 成功 600, 手机号不合法 601, 验证码错误 603, 手机号已注册 607, 缺少必要字段 609... 评论: 成功 1070, 不允许评论 1071, 参数错误 1073, 动态被删除 1075...

5.文档过时，与接口不同步后端把接口改了没有及时通知，前端 /客户端莫名其妙调了半天才发现

6.应用界面和接口强耦合难分离比如某个版本的 QQ 空间动态的 JSON 结构必须对应某个版本的某个接口，有时候 JSON 结构甚至是由后端拍脑袋决定的，不好用也得用

7.版本迭代导致大量重复功能的接口为了兼容旧版应用不好直接改原来的接口，一般只能新增

8.前端 /客户端与后端扯皮前端 /客户端想要一次性返回或者更方便解析的结构，但后端想要少写代码

9.数据库操作不安全 delete 忘加 where 直接删光全部数据，只要发生一次

10.开发流程繁琐周期长后端写接口>后端写文档>前端 /客户端查文档>(前端 /客户端关于文档向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端调用接口>(前端 /客户端关于实际使用向后端提问>后端解决问题并通知或等待再次被问)>前端 /客户端解析返回结果>(前端 /客户端关于返回内容或结构向后端提问>后端解决问题并通知或等待再次被问)

如何通过SDL定义数据类型？
```
type Persion {
name: String!
age: Int!
}
```
! 代表必填。
```
type Post {
title: String!
author: Person!
}
```
可以作为其它scheme的类型。
```
type Person {
name: String!
age: Int!
posts: [Post!]!
}
```
posts:[Post!]!代表posts字段是数组的元素是Post类型，并且必填。
如何使用GraphQL 读数据？
```
{
allPersons(last: 2) {
name
age
posts {
  title
}
}
}
```
获取所有person的name。

如何通过GraphQL 写数据？ Mutation: Create、Update、Delete。

// Create
mutation {
createPerson(name: "Bob", age: 36) {
name
age
}
}

如何通过GraphQL建立client与server的长连接？
```
subscription {
newPerson {
name
age
}
}
```
GraphQL中的scheme是什么？ allPersons/createPerson/newPerson等等。
```
type Query {
allPersons(last: Int): [Person!]!
}
```

type Mutation { createPerson(name: String!, age: Int!): Person! }

type Subscription { newPerson: Person! }

type Person { name: String! age: Int! posts: [Post!]! }

type Post { title: String! author: Person! }

FrankKai / FrankKai.github.io

GraphQL入门 #147