GraphQL 简介

What？

       GraphQL 是一种相似于 SQL 的结构化查询语言，由 facebook 于2012年创造，于2015年开源。SQL 在服务端定义，GraphQL 在客户端定义，也就是说 GraphQL 将数据的操做控制权从后端转移到了前端。

       facebook 创造 GraphQL 的目的是取代之前用的 Restful API，这个方案之漂亮，连 jQuery 之父也忍不住啧啧称叹：

Why？

       传统的 Restful API 存在的主要问题是没法灵活、精准的匹配前端的数据需求。

　　首先，产品的需求常常变，因而前端须要的接口也常常变，好比遇到版本迭代，即使整个数据库结构没有任何变化，经常也须要重写或新增不少接口。其次，前端存在不一样的平台，可能对同一类数据的请求，web 端和 app 端须要的字段是不同的。

　　后端的接口要作到与前端的需求一一匹配，会极大的增长后端的工做量，因而后端可能会采起这样的方式：“为多个请求提供一个接口并集，而不是分别为每一个请求单独提供接口”，“有现成可用，就尽可能不新增接口”，好比前端须要两个接口 {1, 2}、{1, 3, 4}，后端只需提供一个接口 {1, 2, 3, 4}。

　　因而前端对数据的需求和后端提供的接口经常没法精准匹配。前端总会遇到这样的状况：请求的接口经常返回不少冗余数据；为了拿到一组数据，不得不发送多个请求；请求到的数据不符合须要的格式，不得不作额外处理；有时某个接口就只少了一个字段……

　　一方面冗余的数据和屡次的请求必然会影响产品体验，另外一方面围绕 Restful API 创建的先后端协做模式会致使大量沟通成本，须要约定、须要接口文档、甚至还须要“联调”。

　　解决问题的办法能够是“深刻推动先后端技术融合、全面增强先后端协做沟通、狠抓落实文档规范……”，这些都是办法，但对于 facebook 这种体量的产品，靠人力解决上述问题的成本多是咱们没法想象的，并且这也不像是技术人员解决问题的方式，至少 facebook 的工程师不这么想。

　　近年来 web 开发的基本趋势是从后向前移，愈来愈多的逻辑在前端处理，可是接口仍然须要后端提供，前端老是要等后端喂接口，后端写的接口老是要等前端来验证，那么为何 SQL 不能让前端来写呢？这就是 GraphQL 提出的解决方案：由前端来定义所需数据、发送查询命令，服务器根据请求自动查询数据库并按指定的数据结构返回数据，用啥取啥，后端只提供服务，而再也不关心具体的业务。

　　自动化实现，应该永远是每一个程序员解决问题的第一思路。

 

How？

      

　　前端向服务端发送的 GraphQL 就是一串字符串，它的结构和 json 相似，其中包含增、删、改、查的指令，括号中定义了一些参数。服务端收到请求就会根据指定的指令、字段和参数返回所需的结构化数据。简单的说，就是前端发送只有属性名，而没有值的 json，服务端返回填充了值的 json。

       具体的教程网上已有很多，在此不作深究。本文目的重在对技术的理解，而非对技术的使用。

 

Pros？

　　一、网络层数据无冗余。特别是在移动端，冗余数据可能带来不小的延迟；

　　二、先后端沟通成本低。根本用不着联调，后端也用不着写什么接口文档；

　　三、灵活应对各类变化。前端取数据跟吃自助餐似的，私人订制，予取予求；

 

Cons？

　　既然这么牛，怎么彷佛没啥人用呢？

　　如下参考尤雨溪的回答：https://www.zhihu.com/question/38596306?sort=created

　　一、服务端结构必须符合 GraphQL spec 的规范，这意味着后端须要重写；

　　二、GraphQL 很是适合特定的前端框架如 React，对于不使用前端框架的公司，就比较尴尬了；

　　三、数据库查询这一层的性能优化比较难作，对于 facebook 这不是问题，对于其它公司可能就是个问题；

　　四、GraphQL 须要后端配合，然而因为路径依赖、风险厌恶等可能的因素，前端要推进 GraphQL 必然会遇到各类阻力。