GraphQL
上午,佳佳分享了有关GraphQL的议题。听完之后,我觉得这个东西貌似没有啥用啊。之后自己搜索了相关资料。貌似懂了一点。
GraphQL是什么?
GraphQL是Facebook出品的。官方说graphql是一个新的和不断变化的语言。它主要提供了客户端进行数据查询的能力。
要想知道一个产品有没有用,先看看它是在什么场景下被搞出来的。
1 | GraphQL产生的背景却完全不同,在facebook内部,大量不同的app和系统共同使用着许许多多的服务api,随着业务的变化和发展,不同app对相同资源的不同使用方法最终导致需要维护的服务api数量爆炸式的增长,非常不利于维护(我们主要在restful场景上思考)。而另一方面,创建一个大而全的通用性接口又非常不利于移动端使用(流量损耗),而且后端数据的无意义聚合也对整个系统带来了很大的资源浪费。 |
1 | ###GraphQL对比Rest |
一句话,就是接口太多了,后端写起来,维护起来太麻烦。写了一套框架,直接把这些查询权限扔给前端。前端想怎么玩就怎么玩。关我们后端屁事。
我的看法
1、首先,如果玩这个。对于全栈人员来说是友好的。在后期维护中直接操作前端就可以了。我觉得是可以采用的。
2、如果不是全栈,那么会增加后端人员,前端人员的代码学习成本。还有前后端人员的协调沟通。还有后端人员之后是省事了,但是前端的工作量却增加了,如果前端人员水平不够,会影响整体。我觉得没必要采用。
3、如果是小应用,api不是很多的情况下(比如几十个以下,也可以采用api网关来处理),没必要花费那么多的时间成本去增加这个东西。
4、还有安全性的问题,后端如果直接把操作数据的权限扔给前端,真的可以吗?如果有恶意分子,是可以做很多攻击的。
总结
少量api | 大量api (几十个之内) | 超级量api |
---|---|---|
不处理(安全性可以) | 使用api网关(安全性可以) | 考虑使用GraphQL(安全性不好) |