在写一些接口的时候,有时候会有一些接口数据,你没有办法直接使用,无论是计算也好,还是逻辑也好,都是需要再对数据进行一些处理才能使用。在处理完后,才能进行下一步操作,比如最直接的UI分类填充等。那么关于一些需要处理的数据,处理过程到底是放在前端还是后端好呢?以服务器端+移动端为例,我将我的一些思考记录如下,个人想法,欢迎讨论交流。
首先放一个不严谨,但是最简单,而且绝大部分时候可行的方案(前端的小伙伴不用谢哈哈):当一项工作如果前端和后端都能做,一定让后端做!
后端的同学可定要喷我了🤣,这确实存在很多问题。
首先,对于移动端一些简单的页面,其实需要的数据反映到后端上,需要返回的数据结构的逻辑其实就是设计的表结构逻辑上。
比如一个前端页面需要展示的是一个用户信息,那么后端其实直接取user表中的相应user对象直接返回即可(当然一些敏感隐私字段可以序列化时选择不返回展示)。这个时候,很多的后端同学实际上提供的是面向数据库的接口。
但是针对一些复杂一点的场景,后端直接根据表结构的思维逻辑进行返回,前端在拿到数据的基础上,还得做了很多判断处理。
也就是说后端返回的业务层数据,和前端需要的展示层数据存在不一致的问题。
针对这种问题,你是选择将转换逻辑放在前端做呢?还是后端做好处理返回给前端直接展示?下面我简单的分析一下。
逻辑放前端:
1 后端计算成本高,增加服务器计算和 IO 开销;
如果这个接口的计算结果可以被缓存,这个优势就没那么重要了。如若不然,逻辑放前端可以分散开销到每台手机上,节省了服务器性能资源。
2 前端计算精度、兼容性可能存在问题;
逻辑放后端:
1 增加移动端计算和 IO 开销;获得整体更好性能甚至更低延迟;
这个很好理解,要么增加服务器开销,要么将开销分散到每台手机上。但对于一些采用了缓存机制的接口而言,更好的复用可以降低计算次数,从而降低总体计算量,甚至在频繁请求时,也可以降低时延。所以当后端设计合理时,放在后端处理可以最大程度的减少服务器开销,同时提高手机用户的体验。
2 业务解耦:多端展示时,改动逻辑只需要改后端;
如今一个后端,基本上需要面向ios、Android、小程序、网页等提供接口。如果业务逻辑稍有变动,而业务逻辑的处理放在了后端,那么将不影响前端展示,只需要改后端即可。因此在需求改动时,后端效率要高于前端,并且如果有进一步扩展也有快速的解决方案。
3 算法保密性更好,高复用;
所用到的算法对大前端而言通用。为何谈到保密呢?试想一下,如果用户通过网络抓包拿到了你的接口数据,一看字段什么**VIP,是很尴尬的。这个时候,不用想了,服务端做!
4 节省流量;可复用性高;
api是要复用的,如果下一个项目也用到了这个api,原来的处理的逻辑还要重新复制粘贴。
当然不管选择哪种都有一些核心原则:
1 逻辑判断、权限要验证之类永远放后段:
比如商品的免费与否,前端不应该根据你返回的类似于表示限时免费的字段、已购买未购买的字段,或者其他业务上的种种逻辑字段来判断商品的isNeedPay。isNeedPay这个商品属性字段应该由服务器判断,如果不然,反编译orhook等技术将使得你的app变成外挂殖民的天堂。
再比如登陆接口,不同的登陆可以分类,微信登陆时,接口有一个classify字段值为1,密码登陆时的classify=2。如果当前端选择密码登陆时,还传了多余的字段信息比如wxName,此时前端的工作可以清洗下数据,比如classify=2即密码登陆时,就不再传微信的相关字段,但是无论前端做不做这样的清洗,后端都必须要做清洗工作——因为没有办法保证这个 api 不会被攻击。
2 业务逻辑永远放在后端:
例子同上,前端的逻辑永远是可以被绕过的。并且总的来说,业务系统(后端)可以用很久,但是前端(客户端)可能用一段时间就会更换。
3 核心业务(比如金钱),前后端都要校验逻辑:
同样是上面的例子,上述例子中,不代表前端不需要做判断了,涉及到money的,前后台的判断都很重要,必须做到完全防护。
4 大量数据的预处理放在服务器端做:
首先数据的预处理服务器端来做,清洗工作是不可能放到前端的。其次,cpu密集型计算更多的也还是交给服务器来完成,毕竟别的先不说,光说服务器实在性能不行,还可以无限扩容提配,而客户端是不可能换手机换浏览器的,这辈子不可能换!
5 需要什么返什么:
这看上去是一句废话,但接口的返回逻辑应该是产品/业务/app的展示所需数据的逻辑,这和表的设计有时候并不重合。
总结
其实这个问题其实没有绝对的方案,而在于技术选型、场景划分和产品需要。
前端是面向用户的, 最适合的数据形式是按UI结构定义的;后端是面向业务的, 最适合的数据形式是按业务逻辑定义的;
服务器端的原始数据,考虑的是结构化、检索优化、存取优化、iO 优化等问题。原始数据到后端业务层,肯定会进行枝剪裁切,变为符合业务层处理的数据结构,而这部分内容的结构不一定完全适合展示层直接拿来用。此时前端就会处理下后端的数据,变为自己用着方便的格式。如果后端完全做数据中转,把原始数据不按业务做枝剪,一股脑都扔给前端,那肯定是不合适的。一个是造成多余的业务数据泄露,另一个是平白增加响应体积浪费带宽以及恶化前端性能。但非这种情况下,前端将指定业务层数据转化为展示层的数据结构来用,是完全正常的情况。
另外,后端接口的数据有原子化趋势,造成一些前端的接口和业务分离,最典型的就是在app中,嵌套接口请求以及不同数据流的merge操作越来越多。基于restful架构,后端给出基础资源的接口,前段基于业务自己组合。
由于上述的种种原因,慢慢也开始发展出了一套中间数据层的概念,也有人称为数据中台。拿BFF举例, Backend For Frontend(服务于前端的后端)又称为用户体验适配器,它只是一种逻辑分层,旨在做服务器API设计时也考虑前端的使用,并在服务端直接进行业务逻辑的处理。但是最近我看阿里的中台实施的好像并不算太成功。有兴趣的同学可以看看这个数据服务层解决方案Pont,它可以利用接口元数据,高度定制化生成前端接口层代码,接口 mock 平台和接口测试平台。
最后小结
真正的实施中需要有足够的广度和宽度去思考整个系统层面的需求、影响和实现,设计者需要对前后端都有一定的储备,并在设计时分析前后端成本,谁做方便?谁做灵活性好?谁做交流成本低?
但对于一般的小公司而言,组合原生数据并不管前后端,只有业务稳定下来后,才思考合理性、解耦性。这是最符合业务时间要求的。所以:
你来写!
能跑就行了!
又不是不能用!
我嗓门大我不做!
领导说谁做谁就做!