天天看点

新技术探究之 GraphQL

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

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

新技术探究之 GraphQL

Why?

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

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

  后端的接口要做到与前端的需求一一匹配,会极大的增加后端的工作量,因此后端的基本原则是“为多个请求提供一个接口并集,而不是分别为每个请求单独提供接口”,“有现成可用,就尽量不新增接口”,比如前端需要两个接口 {1, 2}、{1, 3, 4},后端只需提供一个接口 {1, 2, 3, 4}。

  于是前端对数据的需求和后端提供的接口常常无法精准匹配。前端总会遇到这样的情况:请求的接口常常返回很多冗余数据;为了拿到一组数据,不得不发送多个请求;请求到的数据不符合需要的格式,不得不做额外处理;有时某个接口就只少了一个字段……

  一方面冗余的数据和多次的请求必然会影响产品体验,另一方面围绕 Restful API 建立的前后端协作模式会导致大量沟通成本,以致于尽管前后端分离了,很多团队的开发环节仍然离不开旧时代的“联调”。

  解决问题的办法可以是“深入推进前后端技术融合、全面加强前后端协作沟通、狠抓落实文档规范……”,这些都是办法,但对于 facebook 这种体量的产品,靠人力解决上述问题的成本可能是我们无法想象的,而且这也不像是技术人员解决问题的方式,至少 facebook 的工程师不这么想。他们的解决方案是:前端定义所需数据结构,后端根据数据结构自动查询数据库并按指定的数据结构返回数据,用啥取啥,真正实现后端云服务化。

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

How?

新技术探究之 GraphQL

  前端向后端发送的 GraphQL 就是一串字符串,它的结构和 json 类似,其中包含增、删、改、查的指令,括号中定义了一些参数。服务端收到请求就会根据指定的指令、字段和参数返回所需的结构化数据,所见即所得。

新技术探究之 GraphQL

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

Pros?

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

  2、前后端沟通成本低。根本用不着联调,后端也用不着写什么接口文档;

  3、灵活应对各种变化。前端取数据跟吃自助餐似的,私人订制,予取予求;

Cons?

  既然这么牛,怎么似乎没啥人用呢?

  以下参考尤雨溪的回答:h t t p s : / / w w w .z h i h u .c o m / qu e s t io n / 3 85 9 6 30 6 ? s o r t = cr e a t ed 

  1、服务端结构必须符合 GraphQL spec 的规范,这意味着后端需要重写;

  2、GraphQL 非常适合特定的前端框架如 React,对于不使用前端框架的公司,就比较尴尬了;

  3、数据库查询这一层的性能优化比较难做,对于 facebook 这不是问题,对于其它公司可能就是个问题;

  4、GraphQL 需要后端配合,然而由于路径依赖、风险厌恶等可能的因素,前端要推动 GraphQL 必然会遇到各种阻力。

本文转自lzwxx 51CTO博客,原文链接:http://blog.51cto.com/13064681/1944346