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