手机版 欢迎访问it开发者社区(www.mfbz.cn)网站

当前位置: > 开发

Graphql的思考

时间:2021/6/11 22:10:49|来源:|点击: 次

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中获取名称,本身是键值对的他们取的时候也很方便。

选择

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

 

图片

Copyright © 2002-2019 某某自媒体运营 版权所有