Graphql的思考

Posted 2021-04-30 悠然亭记

Graphql简述

   graphql是facebook发布的一查询语言规范。

执行流程

简单的理解它的工作原理，可以理解根据前端请求而进行的方法调度器

1. 前端按照规范传来数据比如要查a对象的一个属性，graphql会根据a对象找到对应的a方法，在这个方法里面我们写自己的逻辑，从数据库或者缓存之类的获取数据，返回给前端，查b对象一样调用b方法，如果只查一个a对象，graphql只执行a方法，同理查b对象，

2. 如果前端需要两个一起查，就传两个对象，graphql并行执行两个方法返回给前端，

3. 如果两个对象有关系，我们对他们的属性也建立了关系，比如a里面有b对象，查询的时候前端传a还是只执行a的方法，如果要查a对象中b对象的某个属性，则先执行a方法，在执行b方法，因为可能需要用到a对象的一些属性作为b的查询参数。

思考

它的工作流程很简单，但很值得我们思考，相当多的公司在使用graphql之后他们发现不应该在让后端处理页面展现的逻辑了，只有这样才能让服务的能力得到下沉

好处

在上一家公司的时候，我们是这么做的，出发点主要是基于系统的性能考虑，棋牌类的游戏基本没外挂，而fps即时类的游戏外挂很多，核心问题现在fps的服务器帧率一般都是20-30，也就是33-55ms的延时标准，一个玩家发出一个动作，需要在这个标准以内同步给其他人才不会让用户觉得卡，这种情况服务端能做的基本只有一个事情就是事件转发，数据不但不会给前端做处理，而且连验证都不会做。

所以很容易得到一个结论只有服务端做的事情越少，系统的性能才越好，接口需要足够的轻，并发量上来了，并不需要加太多机器，就能得到很大的提高，

按照这个结论得出能让客服端做的，服务端就别做，

于是我们获得了第一个好处，接口变的通用了，和页面表现形式是非耦合的，我们关心页面的数据，而不关心他们的展现形式，让接口能满足多种产品的需求，而后端可能并不需要改动，但这并不是说我们会产生一个全能的接口，这和性能是违背的，而是由于我们的接口足够的轻，所以足够灵活，是以忍受一定的网络通信带来的消耗，而获得的，如果两个数据之前存在强耦合并且有这种合并的需要性，有时候也是会合并的

做完这些，我们发现，我们的接口实际上就是数据，是按照业务分成而得来的数据接口，前端不再被动式的等待后端根据页面提供接口，他们可以从原来的接口获得数据，相互间的协作变的顺畅，

而且由于我们的接口是数据，这对我们进行数据的分层变的非常容易，变化很少的，没有数据安全的，一般都是直接生成js片段，套上cdn前端直接请求，分摊了服务器的压力，变化多的，分层三级缓存，以提升应用的性能

数据分层以后基础数据我们是不返回给前端的，比如城市名称这种，我们只返回ID给他们，他们自己从JS中获取名称，本身是键值对的他们取的时候也很方便。

选择

怎么做是与团队和项目的发展程度息息相关的，没有最好的方案，只有符合当下时间比较恰当的选择，需要权衡各方面的利弊，让团队的开发效率达到最高效