Bustle 的 GraphQL 实践

  • David Iffland
  • 薛命灯

2017 年 10 月 12 日

话题:JavaScriptFacebook语言 & 开发

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

JavaScriptFacebook语言 & 开发