如何看待后端接口带出数据库全部字段

这些 null 再数据库是不是 None,数据库没给默认值吗

@NjcyNzMzNDQ3

取模应该放在前端还是后端？

我的界限是：

1 ，业务展示要求，一般放前端，但是非常大可能性经常变得，放后端；
2 ，业务逻辑需求，一般放后端，除非前端运算能带来体验大幅提升且无发作用；

所以这是一门艺术。

一种是淡化后端逻辑，前端根据不同平台 h5/app ，个性化输出
一种是后端整理逻辑，前端纯展示

当然现实中两者的边界，可能是动态变化的。

看场景吧，如果你这就是个内部后台管理系统，直接维护 DB 的，这么操作不很正常么？或者是一个后台内部公共服务，面向的业务会用到哪些字段是不确定的，怎么去砍字段？如果是对接前端的业务接口，就应该按业务需要重新定义一下。

取模于 10 这个个人觉得交给前端做好些
这个 null 返回挺纠结的，不处理确实不安全容易暴露表结构以及占用传输带宽，但是一个查询接口就需要写一个对应的 VO 的话会不会又导致项目过于冗余庞大

结论：少一个架构师

1. 在做业务之前没有定义好 API 的输入与输出，如果事先定义好了，后端专心返回对应数据（即便是多了一些数据，到时候的性能问题排查也肯定是后端的问题），前端专心根据 mock 设计页面逻辑（没必要纠结多个字段，少个字段）

2. 开发流程，从你拿到后端接口数据才抱怨就很明显知道了，前端要等后端开发完接口才能规划数据，完全没有必要啊，就拿你的取模来说，result = response.data.datamod 和 result = response.data.datamod % 10 两个区别很大吗？何必一定要完完整整的你要什么给你什么呢？那如果有一天你要计算哈希值也先帮你算好？

简单来说，后端负责业务数据的存储，安全，稳定，一致，前端负责展示数据，解析数据，计算数据。

其实说到最后就是工作量的问题，如果需求变动，谁来改，就单单你说的取模，需求变成取模 100 ，要么后端改，要么前端改，你们要不掰个手腕？

@Cielsky 他就是后端管理 = =

“哪怕是取模于 10 这种简易操作也要前端来做”

只是讲我们后端不灵活的一个例子

这个问题的出现是，后端的某个状态值 1 ，2 ，3 分别对应不同状态，并且告诉我，11 、12 、13 也是相同的状态，你取模一下 10 就行了

我不同意是因为
1. 前端并不需要知道 1 和 11 的区别，所以前端只需要知道 1 个值对应一个状态就行了
2. 因为该项目是多端项目，接口存在复用，如果这种取模于 10 存在多个项目中，会很难管理