由前后端数据处理分配引发的一些思考

在写一些接口的时候，有时候会有一些接口数据，你没有办法直接使用，无论是计算也好，还是逻辑也好，都是需要再对数据进行一些处理才能使用。在处理完后，才能进行下一步操作，比如最直接的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 平台和接口测试平台。

最后小结

真正的实施中需要有足够的广度和宽度去思考整个系统层面的需求、影响和实现，设计者需要对前后端都有一定的储备，并在设计时分析前后端成本，谁做方便？谁做灵活性好？谁做交流成本低？

但对于一般的小公司而言，组合原生数据并不管前后端，只有业务稳定下来后，才思考合理性、解耦性。这是最符合业务时间要求的。所以：

你来写！

能跑就行了！

又不是不能用！

我嗓门大我不做！

领导说谁做谁就做！