Bustle 的 GraphQL 实践

Facebook 将 GraphQL 定义成“一门 API 查询语言以及一个支持查询现有数据的运行时”。REST 通过向 REST 端点发送请求获取数据，而 GraphQL 允许客户端指定它们想要的数据。

当 Facebook 公司内部开始大规模使用 GraphQL 时，社区才刚刚开始使用 GraphQL。InfoQ 采访了来自 Bustle 的工程总监 Steve Faulkner，谈论了 GraphQL 的相关问题以及 Bustle 如何使用 GraphQL，并为想要采用 GraphQL 的团队提供了一些建议。

InfoQ：GraphQL 在 Bustle 的应用情况是怎样的？

Steve Faulkner：GraphQL 现在在我们的生产系统里扮演着非常重要的角色。我们所有的 API、后端的 CMS 系统和前端的网站都从 GraphQL 获取数据。我们有两个独立的技术栈，后端的 CMS 内部系统和前端的 Preact 应用，它们都与 GraphQL 发生交互。

InfoQ：在切换到 GraphQL 之前，Bustle 使用的是什么技术？

Faulkner：我们之前主要使用的是 Rails 风格的 REST。在一开始我并不喜欢 GraphQL，甚至极力阻止想使用 GraphQL 的人。我认为“REST 已经足够好了，它什么都能做，而 GraphQL 太复杂了，我不知道该怎么把它引入我们的系统里，我不想把我们的技术栈搞得太复杂”。

但后来有两件事情改变了我的看法。首先是类型系统，GraphQL 的类型系统降低了我们的沟通成本，提升了我们的开发效率。第二点，我们的前端开发人员很快就能够上手，刚刚在生产环境进行了试验，就有很多人开始使用 GraphQL，因为他们不需要向别人请教任何问题就能够轻松使用它。他们会说：“如果我需要一个新查询，自己就能搞定”。

InfoQ：你们是怎么做出切换到 GraphQL 的决定的？

Faulkner：我们的工程团队在技术上很自由。我们很信任我们的开发人员，他们可以构建他们认为值得构建的东西。我们的一个开发人员说“我认为 GraphQL 是未来的趋势”，我觉得他说得没错，于是我们就开始尝试 GraphQL。我们的团队有一个习惯，如果我们看到了一些很酷的技术，就会把它放到生产环境进行试验。

InfoQ：GraphQL 为你们解决了哪些问题？

Faulkner：它首先解决了人员沟通问题。GraphQL 为 API 或文档的变更提供了开箱即用的解决方案。它是一门比 REST 更加严谨的 API 开发语言，它强制你开发出更好的 API，同时可以自动生成文档。它自带的 API 浏览器（explorer）完全是自动化的，它帮我们做了一些事情，虽然这些事情不是很难，但毕竟为我们节省了时间，加快了我们的开发速度。

InfoQ：想要切换到 GraphQL 的团队需要考虑哪些问题？

Faulkner：GraphQL 也存在一些不足，比如安全方面的问题、在生产环境中的运维问题、查询的复杂性、认证和授权问题。我们自己解决了当中的一些问题，但这些问题在社区方面并未得到解决。这些问题需要得到重视。如果有银行想要使用 GraphQL，需要想想“要做些什么来让它达到生产级别”。

Faulkner 在 2017 伦敦 QCon 大会上呈现了有关他们如何在 Bustle 使用无服务器架构来支持他们后端系统的演讲。

查看英文原文： Switching to GraphQL at Bustle