###GraphQL对比SQL
首先，官方说了，GraphQL是一个查询语言，而且目前还未完成，意味着未来可能会有更多更大的变动。
单这并不妨碍世界上那么多前端工程师的折腾之路！查询语言？那就是说和sql类似喽？你看名字里都有“QL”啊～
确实如此，确实是用来声明要查询的数据的，但要解决的问题却完全不一样，伴随我们多年的sql主要解决的是如何在数据库基础上提供简单易用且功能强大的沟通语言，使得我们人类可以轻而易举的从海量数据中获取到我们想要知道的数据片段。
GraphQL产生的背景却完全不同，在facebook内部，大量不同的app和系统共同使用着许许多多的服务api，随着业务的变化和发展，不同app对相同资源的不同使用方法最终导致需要维护的服务api数量爆炸式的增长，非常不利于维护（我们主要在restful场景上思考）。而另一方面，创建一个大而全的通用性接口又非常不利于移动端使用（流量损耗），而且后端数据的无意义聚合也对整个系统带来了很大的资源浪费。
在这样的背景下，fb工程师坐不住了，于是乎GraphQL的概念就诞生了～最了解客户端需要什么数据的只有客户端自己，所以如果给客户端提供一种机制，让其表述自己所需的数据结构，这岂不是最合理的么？
###GraphQL对比Rest
目前，最热的前后端通信方案应该是Restful，基于http的轻量级api，前端通过ajax请求服务端提供的rest api完成数据获取。
我们再往前一步，假设你的项目前端已经组件化了，一个业务肯定是需要多个组件结合来完成的，每个组件都各自管理自己的内部状态和所需数据，那么，目前的做法是，一旦前端路由匹配了对应的业务页面，那么自然会加载相关的组件实现，同时，你还需要调用rest api来获取组件所需数据。
不同的页面，组件的组合肯定也略有不同，不同的组件组合后，所需的数据自然也不会完全一致。这里你可能会说，既然以组件为单位复用，那rest api针对组件颗粒度提供一对一的服务即可，话是没错，但实际操作起来就不work了，试想前端狗被产品狗每天要求加这加那，前端狗就会不得不去求后端狗协同开发，这样最后就剩下死逼了！而且前面也说了，这样做创造出来的大量的api会变得无法维护～
那么，是时候考虑采用Rest以外的解决方案了！（尽管我认为，GraphQL并非是来取代Rest的，但为了我们的描述简单，这里就直接这么写了！）后端根据GraphQL机制提供一个具有强大功能的接口，用以满足前端数据的个性化需求，既保证了多样性，又控制了接口数量，完美～
###GraphQL到底是什么
A GraphQL query is a string interpreted by a server that returns data in a specified format.
这端描述如果不了解它的背景，确实很容易和sql混淆～但，现在，你应该知道GraphQL到底是个什么鬼了吧～
好的，下面我们就来开始GraphQL in Action!
有话要说