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

[mokevip]

直接从数据库中取得模型，不需要的值就是一堆 null

如果是需要额外处理的字段，就在原本对象内放一个 params 的对象，再嵌套一层放处理的数据

能因为一个值需要转换一下数据而扯皮，哪怕是取模于 10 这种简易操作也要前端来做

[darkengine]

@rabbbit 0 和 1 还算好的，以前接过一个屎山，后端返回来的布尔值是 1 和 2 。。。。。。。

[jorneyr]

@yedanten 你这是想给数据库字段加密么。

[Qseven]

对这种一个实体从底贯穿到外的做法，十分鄙视，写什么代码，麻烦回去种田。

[seakingii]

建 VO 是好习惯

不过为了能早点下班的话懒点也能理解...

[yyf1234]

艸，以为看到我公司的代码了

[labulaka521]

@yyf1234 +1

[labulaka521]

@darkengine 哈哈 我们用的 grpc + golang 布尔值在 proto 里就是定义成 1 或 2

[Dragonphy]

我竟然觉得没什么问题[假笑]，不想要无关字段可以针对不同的需求建立 VO ，而且前端取模也没啥大不了的吧，我们的后端我让直接写 SQL[二哈]

[sampeng]

这种后端写什么程序，回家种田吧。

先不说偷懒不偷懒，不摸鱼的员工不是好员工。

单说反正机器流量钱不是他出，按 LZ 的这个例子，最少流量费用要多出 50%出来。服务端 GZIP 需要 cpu 。cpu 利用率多出 50%。客户端需要解压缩，需要 get body ，客户端也是要损失一部分损耗在里面。

你们后端 leader 是吃屎的？这都不管？那管啥？

[rabbbit]

@sampeng
息怒，这都不算啥，你还没见过批量删除让前端自己写循环发请求挨个删的。

[dengshen]

@TUNGH 做 node 不仅要重写 vo 还要重写 dto 日了狗了

[ccppgo]

既然是 java 。。属性为 null 这种东西用 jackson 处理一下不就好了么

[asfas1246]

我一个接口，返回了 45 万个字符。其中需要的，10%都不到。

[aliveyang]

什么阶段干什么事，不怎么重要的项目套模板没什么不好的

[Cielsky]

@mokevip 那你跟后端管理说不就完事了，然后保留聊天记录方便甩锅即可

[XCFOX]

这时候就体现出 GraphQL 的好处了，后端还是直接抛从数据库里取出来的对象，前端需要什么按需取就行了

[PopRain]

楼上说的一个对象用到底就鄙视不能认同， 大部分企业应用有复杂的逻辑和界面，每个界面（前端）对应一个 VO ， 那管理起来太复杂了。。。。

[unnamedhao]

前后端接口规则咋定，一般看谁能打过谁

[morize]

作为前端，我觉得返回 null 没什么问题，做数据防御是基本的好吧。可选链 ?. 又不麻烦。
多余的字段怎么说呢，难道来需求了前端后端一起改吗，太麻烦了吧。
觉得不好自己再 format 一次咯，要是你习惯把接口的数据直接抛到 view 层当我没说。

[lanlanye]

暴露了表结构可能是一个问题，另外如果冗余数据的内容非常多导致传输受到影响也不好。
除此之外其实没什么太大的问题，而且我个人的看法是少量的计算和格式转换交给前端做更好，毕竟前端的计算压力分散在每一个客户端（浏览器）上，而后端处理则是一台服务器处理所有请求需要的数据，显然前端处理可以分散压力。

当然实际项目中大部分人这么做是因为懒（摊手