前言

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

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

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

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

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

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

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

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

作者