GraphQL实战写给全栈工程师们 pdf下载

适读人群 ：全栈程序员，前端程序员，后端程序员，大数据工程师，算法工程师和技术型产品经理

涵盖当下流行的移动互联网应用前后端和大数据平台开发，教你如何在高并发海量数据环境下提升用户体验和响应速度

GraphQL能让前后端数据通讯更顺畅，提高应用反应速度，加快应用开发速度，这对全栈、前端和后端程序员来说是非常有吸引力的。目前，GraphQL已经被Facebook、Google、 、Twitter、GitHub、eBay等IT公司接受并投入实际使用。

《GraphQL实战——写给全栈工程师们》以当下流行的移动互联网应用开发为切入点，结合作者多年的前后端实际架构经验，针对目前互联网上程序员们对GraphQL的疑问和误解，并辅以业界真实案例，对前后端设计中的难点要点分别加以介绍。在前端，本书重点讲述了如何提升用户体验和响应速度；在后端，主要讲解了在高并发海量数据环境下的设计与优化；*后，还介绍了如何让GraphQL与大数据平台整合来训练机器学习模型。

《GraphQL实战——写给全栈工程师们》内容涵盖前端、后端和大数据平台开发，非常适合全栈程序员阅读，也可作为前端程序员、后端程序员、大数据工程师、算法工程师和技术型产品经理提升知识储备的参考书。

Twitter核心服务组高级研发工程师，毕业于美国Syracuse大学计算机科学与工程学院，获博士学位，曾任国内多家公司CTO、技术总监、首席架构师。

在前后端以及全栈研发一线奋斗十余载，专注于高并发、高可用微服务平台以及大数据平台架构，拥有重构并优化千亿级日访问量微服务以及数据采集经验。力求用浅显的语言来讲述亲身的实战经验和国内外的先进理论，以满足中国互联网行业的实际需求。

前言

导读—本书为快速学习设计

第1章 GraphQL API设计和全栈开发1

1.1 什么是GraphQL2

1.2 分布式系统2

1.2.1 扩展性3

1.2.2 可靠性3

1.2.3 远程资源共享4

1.2.4 更强的处理能力4

1.3 C/S架构与API4

1.3.1 C/S架构4

1.3.2 前端与后端5

1.3.3 全栈程序员5

1.3.4 应用程序接口6

1.4 RESTful API的起源与特点7

1.4.1 仓库保管员的窘境7

1.4.2 REST无状态的好处8

1.4.3 RESTful API是否真的无状态8

1.4.4 RESTful API是否是数据传输协议9

1.4.5 RESTful API的好处是什么9

1.5 RESTful API的主要问题10

1.5.1 数据定制的问题10

1.5.2 多次请求的问题10

1.5.3 异常处理的问题10

1.5.4 返回数据格式未知的问题11

1.5.5 请求Endpoint和方式过多的

问题11

1.6 GraphQL如何解决RESTful API的

问题11

1.6.1 GraphQL可以自由定制数据11

1.6.2 GraphQL可以把多次请求合并为

一个12

1.6.3 GraphQL错误以及异常信息

明确12

1.6.4 GraphQL返回数据的形式和查询

请求同构13

1.6.5 GraphQL使用单一的Endpoint14

1.6.6 GraphQL替代了什么14

1.7 GraphQL引发的疑虑15

1.7.1 GraphQL是否还是RESTful15

1.7.2 GraphQL增大了后端系统设计的

难度15

1.7.3 GraphQL是否会带来后端性能

问题15

1.7.4 迁移到GraphQL的代价16

1.7.5 GraphQL是该前端驱动还是后端

驱动16

1.8 GraphQL全栈框架的选用16

1.8.1 Relay17

1.8.2 Apollo17

第2章 GraphQL初体验—电商API设计18

2.1 基本开发环境的搭建19

2.2 和GraphQL互动20

2.2.1 实时交互界面GraphiQL的使用20

2.2.2 通过curl发送请求21

2.2.3 使用第三方客户端21

2.3 Schema与定义数据类型22

2.3.1 强类型的查询语言22

2.3.2 服务器端的Schema23

2.3.3 标量类型24

2.3.4 自定义复杂类型25

2.3.5 枚举26

2.3.6 列表以及对象的列表27

2.4 定义操作28

2.4.1 只读查询操作28

2.4.2 可写修改操作30

2.4.3 订阅操作31

2.4.4 传递输入类型31

2.4.5 操作也是字段33

2.5 精炼数据模型与操作33

2.5.1 接口和继承33

2.5.2 联合35

2.6 精炼查询36

2.6.1 使用变量36

2.6.2 使用别名37

2.6.3 使用片段38

2.6.4 类型条件39

2.6.5 使用Directive40

2.6.6 后端工程师的福音41

2.7 简单数据验证41

2.7.1 必填值的验证42

2.7.2 标量值的验证42

第3章 电商网站前端开发44

3.1 GraphQL前端开发要点45

3.1.1 前端开发的主要任务45

3.1.2 前端开发的难点46

3.1.3 前端技术的选型46

3.2 前端React项目初始化47

3.2.1 React特点简介47

3.2.2 React 整合GraphQL前端系统

设计48

3.2.3 创建React前端工程49

3.2.4 安装Apollo客户端49

3.2.5 初始化GraphQL客户端50

3.2.6 手动发送查询51

3.3 只读数据的React UI组件51

3.3.1 构建GraphQL Query查询51

3.3.2 定义列表元素组件52

3.3.3 定义列表组件52

3.3.4 绑定静态查询和UI组件53

3.3.5 使用Query组件54

3.3.6 从Query组件中接收一个参数55

3.3.7 数据的接收以及出错处理56

3.3.8 手动刷新57

3.4 修改数据的React UI组件57

3.4.1 定义一个带有变量的Mutation

操作58

3.4.2 使用Mutation UI组件58

3.5 支持订阅59

3.5.1 什么时候使用订阅59

3.5.2 订阅是如何实现的60

3.6 本地数据60

第4章 基于Node.js的GraphQL后端61

4.1 GraphQL后端架构思想62

4.1.1 “薄”层设计62

4.1.2 “门户”设计64

4.1.3 面向业务设计64

4.2 GraphQL层的职责与实现65

4.2.1 GraphQL层的职责65

4.2.2 GraphQL层的实现65

4.2.3 Resolver函数与分治策略67

4.3 Apollo GraphQL后端框架68

4.3.1 依赖库的安装68

4.3.2 定义和解析Schema69

4.3.3 绑定处理查询操作函数69

4.4 详解Resolver函数72

4.4.1 Resolver的各种返回类型72

4.4.2 Resolve一个类型72

4.4.3 Resolve一个复杂类型字段73

4.4.4 Resolve一个标量字段75

4.4.5 Resolve一个自定义标量字段77

4.4.6 Resolve一个列表80

4.5 GraphQL后端验证以及错误

处理81

4.5.1 简单方式81

4.5.2 使用自定义标量类型进行验证82

4.6 异步IO84

4.6.1 基于异步非阻塞IO的JavaScript

实现84

4.6.2 同步还是异步85

4.6.3 异步Resolver85

4.7 使用JavaScript开发后端服务的

问题86

第5章 基于Go语言协程的GraphQL服务88

5.1 使用协程和上下文89

5.1.1 使用协程的原因89

5.1.2 协程和GraphQL服务90

5.1.3 上下文和作用域90

5.1.4 派生上下文91

5.2 Go语言的Web服务和中间件92

5.2.1 构建Web服务92

5.2.2 Web服务中间件93

5.2.3 基于中间件的后端架构94

5.2.4 数据收集中间件95

5.2.5 数据库会话中间件95

......

这是一本写给一线软件研发人员的书。我希望能借本书把自己多年来的系统设计经验（通俗来说就是踩的坑）和大家分享一下。

我并不是因为看到很多硅谷公司——Facebook、GitHub以及Twitter等都开始大量使用GraphQL了，才跟风写这本书的。恰恰相反，我开始筹划这本书是因为听说了非常多的公司内部为GraphQL产生了激烈的争吵，有的公司是前端工程师很想用，但是后端工程师担心GraphQL性能有问题而拼命阻挠；有的公司是后端工程师很想用，但是前端工程师认为使用GraphQL工作量太大而拼命阻挠。因为前后端的程序员往往会有不同的出发点和诉求，各公司也会有不同的实际情况，而且使用GraphQL也的确会给已有系统的前后端造成很大的改动和影响，让很多公司和团队顾虑重重，一直犹豫不决。我觉得是时候把真实项目中使用GraphQL可能会遇到的种种问题整理出来，写成一本书来和大家分享了。希望大家读后能对GraphQL少一些误解，多一些理性思考，从而做出最符合公司和团队实际利益的决定。

GraphQL肯定不是包治百病的灵药，软件开发中更是没有“银弹”，有所得就必有所失。如果非要说对这个新技术的感受，我更愿意说它是“先苦后甜，痛并快乐着”。我们需要花时间来掌握这门新技术，还要花更多的时间修改已有的系统——这就是“苦”。一旦我们的系统前后端都开始支持GraphQL，那我们的系统就会在灵活性、易用性、兼容性和安全等方面得到很大的提高——这就是“甜”。享受这些好处的同时，往往很多GraphQL服务在某些特定的场景下会遭遇冗余数据查询造成的性能问题——这就是“痛”。最后当我们真正了解GraphQL的工作方式，消除了冗余数据查询，甚至有可能得到了比以前更好的性能和可扩展性——这就是“快乐”。

前面谈到了前端和后端，那这本书是更适合前端工程师还是后端工程师呢？其实在我心中，工程师就是工程师，无所谓前端还是后端，这很符合近年来流行的“全栈”工程师概念。但本书对全栈工程师的知识体系要求，可能还要更广阔——不单单包括前端和后端，还会包括数据库的设计、各种测试技术、容器化部署以及负载均衡等问题。

我开始筹划这本书的时候，恰逢开源社区遇到一件趣事，国内某程序员到一个还挺有名的开源项目下留言——“不要再开发了，学不动了”。类似地，我在很多地方推广GraphQL的时候，也会遇到不少程序员朋友提出质疑，现有的开发工具已经很多了，为什么还要花时间去学GraphQL呢？

是啊，如果什么都学，人的精力终究有限，可要是不学，又担心自己被淘汰。所以我们在学习中要抓住软件开发的关键——API（应用程序接口）的设计。可以说，一套好用的API是一个软件系统的灵魂。而API设计也正是贯穿本书的主线，我借GraphQL这个引子，讲述各种相关的全栈技术，让大家可以做出更好的API，更好的系统。

本书涉及的技术多数是这几年才出现的，很多技术还在活跃开发中，本人受自身技术水平和精力所限，只能尽量把这些技术的最新情况介绍给大家。而且到本书出版时，可能有些东西又有了新的变化。所以我会尽量保持更新我在GitHub上的代码库，希望读者朋友也要以自己的实际使用版本为准，不要盲目复制本书上面的代码。

毕竟GraphQL是非常新的领域，我也在不断地努力摸索。所以本书会存在一些不成熟甚至有错误的地方，欢迎读者朋友在GitHub或者其他社交媒体上和我讨论，我会持续改进。也希望读者朋友不要因为一项新技术在初始阶段的不成熟、不稳定，或者对该技术的一些误解，就对它产生了成见，从而错过学习和使用该技术的好机会。

作者