GraphQL是个什么玩意

GraphQL

上午,佳佳分享了有关GraphQL的议题。听完之后,我觉得这个东西貌似没有啥用啊。之后自己搜索了相关资料。貌似懂了一点。

GraphQL是什么?

GraphQL是Facebook出品的。官方说graphql是一个新的和不断变化的语言。它主要提供了客户端进行数据查询的能力。
要想知道一个产品有没有用,先看看它是在什么场景下被搞出来的。

1
2
3
GraphQL产生的背景却完全不同,在facebook内部,大量不同的app和系统共同使用着许许多多的服务api,随着业务的变化和发展,不同app对相同资源的不同使用方法最终导致需要维护的服务api数量爆炸式的增长,非常不利于维护(我们主要在restful场景上思考)。而另一方面,创建一个大而全的通用性接口又非常不利于移动端使用(流量损耗),而且后端数据的无意义聚合也对整个系统带来了很大的资源浪费。

在这样的背景下,fb工程师坐不住了,于是乎GraphQL的概念就诞生了~最了解客户端需要什么数据的只有客户端自己,所以如果给客户端提供一种机制,让其表述自己所需的数据结构,这岂不是最合理的么?

1
2
3
4
5
6
7
8
9
###GraphQL对比Rest

目前,最热的前后端通信方案应该是Restful,基于http的轻量级api,前端通过ajax请求服务端提供的rest api完成数据获取。

我们再往前一步,假设你的项目前端已经组件化了,一个业务肯定是需要多个组件结合来完成的,每个组件都各自管理自己的内部状态和所需数据,那么,目前的做法是,一旦前端路由匹配了对应的业务页面,那么自然会加载相关的组件实现,同时,你还需要调用rest api来获取组件所需数据。

不同的页面,组件的组合肯定也略有不同,不同的组件组合后,所需的数据自然也不会完全一致。这里你可能会说,既然以组件为单位复用,那rest api针对组件颗粒度提供一对一的服务即可,话是没错,但实际操作起来就不work了,试想前端狗被产品狗每天要求加这加那,前端狗就会不得不去求后端狗协同开发,这样最后就剩下死逼了!而且前面也说了,这样做创造出来的大量的api会变得无法维护~

那么,是时候考虑采用Rest以外的解决方案了!(尽管我认为,GraphQL并非是来取代Rest的,但为了我们的描述简单,这里就直接这么写了!)后端根据GraphQL机制提供一个具有强大功能的接口,用以满足前端数据的个性化需求,既保证了多样性,又控制了接口数量,完美~

一句话,就是接口太多了,后端写起来,维护起来太麻烦。写了一套框架,直接把这些查询权限扔给前端。前端想怎么玩就怎么玩。关我们后端屁事。

我的看法

1、首先,如果玩这个。对于全栈人员来说是友好的。在后期维护中直接操作前端就可以了。我觉得是可以采用的。
2、如果不是全栈,那么会增加后端人员,前端人员的代码学习成本。还有前后端人员的协调沟通。还有后端人员之后是省事了,但是前端的工作量却增加了,如果前端人员水平不够,会影响整体。我觉得没必要采用。
3、如果是小应用,api不是很多的情况下(比如几十个以下,也可以采用api网关来处理),没必要花费那么多的时间成本去增加这个东西。
4、还有安全性的问题,后端如果直接把操作数据的权限扔给前端,真的可以吗?如果有恶意分子,是可以做很多攻击的。

总结

少量api 大量api (几十个之内) 超级量api
不处理(安全性可以) 使用api网关(安全性可以) 考虑使用GraphQL(安全性不好)

如何使用GraphQL