为什么要使用 GraphQL？

说实话，我第一次听说GraphQL的时候，并不知道该怎么看待它。当时我正在看Netflix的工程师们讨论如何使用Node.js扩展他们的微服务，其中一位提到他曾在Facebook早期参与过GraphQL的开发工作。

我被它的名字和简洁的点状标志所吸引，浏览了它的主页，并被首页简洁明了的自我介绍深深打动。通过类型定义和类似 JSON 的声明式查询，我们能够准确地获得所需的结果——既不会传递不必要的数据，也不会产生任何往返请求。

虽然这种 REST 替代方案打破了易于理解的以 URL 为中心的惯例，但它为采用者提供了一些优势。

为什么要创建 GraphQL 服务器？

GraphQL 解决了一些客户端问题，而 Redux 的过度使用，尤其是在 React 应用中，暴露出这些问题的严重性。或许你听说过，人们（包括我自己）几乎什么都用 Redux，即使应用状态管理起来微不足道。这种做法的问题就好比用空袭来打蚊子。就连 Redux 的作者 Dan Abramov 也对它的广泛滥用感到恼火。

嗯，丹，好主意！幸运的是，你在 Facebook 的同事们已经开发出一种产品，它能精准地获取客户所需的信息——不多也不少，从而帮助缓解状态难题。

不再需要过度获取数据或进行往返 API 调用

服务器通过单一接口向客户端提供渲染特定视图所需的所有数据，大大简化了需要配置的应用程序状态。再加上持久化查询、批量处理和订阅等功能，您就拥有了一个超高效的 GraphQL 后端。

想象一下，为了收集足够的数据来渲染应用程序的首页，你需要发起 5 个不同的 REST 端点调用。你很可能需要获取过多的数据——几十个字段都以热量的形式散落在周围的空气中，因为你只需要其中一个响应中的一个整数。来自 60 亿光年外恒星的光线照射到太阳能电池板上，转化为流经你电脑的能量，然后就被浪费掉了。

这种声明式数据获取方式也意味着客户端无需进行那么多往返数据调用，例如刷新页面或获取更多信息流条目。它们只需发送一个更小的查询即可完成这些操作。

请注意，GraphQL 和 REST 并非互斥，您完全可以配置服务器以同时支持这两种技术。这可以通过添加一个专门用于响应GraphQL请求的端点，或者使用GraphQL 服务器封装 REST API来实现。

数据探索

在我看来，数据探索是构建 GraphQL 后端最酷的功能之一。搭建 GraphQL 服务器后，你可以配置它来提供一个 GraphiQL 编辑器（注意是i），以便在开发环境中测试查询。你甚至可以在生产环境中启用这个入口，让用户能够使用你的数据来开发自己的应用程序。这个浏览器内置的 IDE 可以帮助新工程师快速上手，或者让你的团队以简单、声明式的方式探索数据集。从此告别在 MySQL 强大的 Workbench 中摸索，或是没完没了地输入 cURL 命令的繁琐。

您可以探索多个开源的 GraphQL API，例如GitHub、Hackernews和Reddit。
在之前的博文中，我曾使用 Yelp REST API 创建了一张咖啡地图。事实证明，他们也提供了一个面向开发者开放的GraphQL API，开发者可以选择加入他们的 beta 测试版。

当然，允许任何人向你的后端发送查询会存在一些安全隐患。幸运的是，Max Stoiber 写了一篇很棒的文章，介绍了他在Spectrum如何改进 GraphQL API 的安全性。

我的想法

过去几周，我一直在深入研究 GraphQL 规范以及一些让开发变得轻松愉快的实用库。例如，Apollo 团队创建了几个实用程序和大量博客文章，这些都极大地帮助我理解 GraphQL。

Apollo 提供客户端库，使构建 GraphQL 查询变得轻松便捷。他们提供的工具让构建模式变得简单明了。此外，他们还提供了一个引擎，可以对每个查询进行性能跟踪、错误跟踪和缓存。如果您想了解 GraphQL 的方方面面，我推荐您阅读他们的博客。

我写这篇文章是为了整理我对 GraphQL 的思考，看看能否从中获得一些新的想法。如果你想练习构建自己的 GraphQL 服务器，可以看看这篇文章。

如果你想要一个简洁明了、内容全面的视频课程，我推荐Stephen Grider在Udemy上的《GraphQL with React: The Complete Developers Guide》。我就是通过这门课开始学习GraphQL的。

下次再见，继续绘制图表。