Linuxeden开源社区作者 ，译者
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
转自 http://www.infoq.com/cn/news/2017/10/graphql-serverless-bustle