工作中的一些业务要接入 GraphQL，继续学起来。但是中文目前没有很好的成套的入门教程，官网中文文档看的我头大，自学的过程中发现—— How to GraphQL 系列教程 ——写的很明白，对于入门者来说比官网强得多，现将它基础系列、进阶系列和客户端系列翻译成中文输出型学习一波。
从 How to GraphQL 的官方 Github 中 fork 了一份，然后从 master 分支新建了一个 translate-to-chinese 分支，利用原来的 markdown 文件进行翻译。
基础和进阶系列翻译已完成：
接下来翻译 GraphQL 的 Vue-Apollo 的实践教程。
介绍
GraphQL 是一个新的 API 标准，它提供了一个更有效、更强大和更灵活的 REST 替代方案。它是由 Facebook 开发和开源的，现在由来自世界各地的公司和个人组成的大型社区来维护。
API 已经成为软件基础架构中普遍存在的组成部分。简而言之，API 定义了 客户端（client） 如何从 服务端（server） 加载数据。
在它的核心，GraphQL 启用了 _声明性数据获取_，客户端可以在其中指定它需要从 API 中获取哪些数据。与返回固定数据结构的多个端点（endpoint）不同，GraphQL 服务器只公开单个端点，并精确地响应客户端请求的数据。
GraphQL - API 查询语言
现今大多数应用程序都需要从存储数据的服务端中获取数据。API 的职责是为存储的数据提供一个适合应用程序需求的接口。
GraphQL 经常与数据库技术相混淆。这是一个误解，GraphQL 是一种针对 API 而不是数据库的 _查询语言（query language）_。从这个意义上说，它与数据库无关，并且可以有效地用于任何使用 API 的环境中。
比 REST 模式更有效
💡 了解更多关于使用 GraphQL 的理由，请参阅博客。
REST 是一种流行的从服务端公开数据的方法。在开发 REST 的概念时，客户端应用程序相对简单，开发速度远远不如今天。因此 REST 模式非常适合当时的应用程序。然而，在过去的几年中，API 发生了根本性的变化。特别是以下三个因素一直在挑战 API 的设计模式:
1. 移动设备使用量的增加导致对高效数据加载的需求
适配移动设备、低功耗设备和不稳定的网络问题是 Facebook 开发 GraphQL 的初衷。GraphQL 优化了需要通过网络传输的数据量，从而改进了在这些环境下应用程序的运行状况。
2. 各种不同的前端框架和平台
运行客户端应用程序的前端框架和平台的多样性，使得很难构建和维护一个适合所有需求的 API。使用 GraphQL，每个客户端可以精确地访问它所需要的数据。
3. 敏捷开发 & 对功能敏捷开发的期望
持续部署已经成为许多公司的标准，快速迭代和频繁的产品更新也是必不可少的。使用 REST API，服务端公开数据的方式通常需要进行修改，才能满足客户端的特定需求和设计更改，这阻碍了敏捷开发实践和产品迭代。
历史，环境和使用情况
GraphQL 不是仅适用于 React 开发者
Facebook 于 2012 年开始在其原生移动应用中使用 GraphQL。但是有趣的是，GraphQL 大多被选择用于 Web 技术的环境，并且在原生移动技术环境中没什么吸引力。
Facebook 在 2015 React.js 开发者大会 上首次公开谈论 GraphQL，并在不久之后宣布了他们的开源计划。因为 Facebook 总是在 React 的环境中谈论 GraphQL，所以其他开发者花了很长时间才知道 GraphQL 并不仅限于与 React 一起使用。
Dan Schafer & Jing Chen 公开介绍 GraphQL，2015 React.js 开发者大会，观看视频
蓬勃发展的社区
实际上，GraphQL 可以用在客户端与 API 通信的任何地方。有趣的是，诸如 Netflix 或 Coursera 之类的其他公司也在研究类似的想法，以提高 API 交互的效率。Coursera 设想了一种类似的技术，可以让客户指定其数据格式，而 Netflix 甚至已经将其解决方案 Falcor 开源。在 GraphQL 开源之后，Coursera 完全放弃了自己的技术，转而使用 GraphQL。
如今，诸如 GitHub，Twitter，Yelp 和 Shopify 等许多不同公司都已将 GraphQL 用于生产中。
尽管是一项很年轻的技术，但 GraphQL 已被广泛采用。了解还有哪些公司在生产中使用 GraphQL。
有专门针对 GraphQL 的完整会议，例如 GraphQL Conf。还有更多资源，例如 GraphQL Weekly 每周新闻。
前端记事本，不定期更新，欢迎关注！
