后端接口喜欢按照数据库的存储结构返回。
比如说一个表格数据，表头是日期，左边是人。返回的数据类似于
极客观点
项目管理
HarmonyOS
[
{date:'2020/01/02',name:'张三'，count：20},
{date:'2020/01/02',name:'李四'，count：20}
]这样前端处理起来就会比较麻烦，需要对date、name 去重，数据量大可能还有效率问题。
到底是返回更加直观的数据，还是按照数据库的存储结构返回更好？
按照他的说法，接口只管返回数据，到底要处理成什么样子是前台的事情。这句话听着好像也没毛病。
又比如说前台需要几个数字分别是今天的、本周的、本月的。后台会把所有的本月的几百条数据返回，每条数据里面包含一个日期直，让前台去判断累加，其实前端需要的就是三个数字。
这个得具体情况具体分析，不是绝对的要让后端或前端处理，如果量不大，需求不复杂，放在前端倒是没什么问题，还能减轻服务端压力，但是如果需求是有分页这种场景的，通常还是放后端合适，而且去重这种东西SQL就能搞定了
前后端没分离的时候，后端是要处理展现的数据的。前后端分离以后，后端直接丢个对象到前端。对象中有大量前端无用的数据，有时候格式也不适合，需要前端做转换。后端对数据不做处理，会造成传输变大，甚至有时候数据都没脱敏。还有时界面上需要的数据来自多个接口，那么都是前端做还会增加请求数。
可以考虑graphql，或者增加中间层BFF
前端如果需要的数据格式固定（而且是长期需要，不经常变更），那么可以与后端沟通，根据前端这边需要的固定格式做一个api接口，像普通的group by这些操作应该不会占用太多计算资源，而且这个接口写起来也很方便的。
13 回答12.9k 阅读
8 回答2.6k 阅读
2 回答5.1k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
5 回答1.3k 阅读
5 回答1.3k 阅读✓ 已解决
3 回答2.2k 阅读
我做前端的，刚开始那会，我也会抱怨，后端那些人什么玩意，数据都不处理下。但是现在不会了，因为数据在后端处理，会给服务器造成压力，这个压力随着数据量和用户量的增加是不断增加的，而数据在前台处理，相当于实现了分布式，每个客户端都是一个小服务器，大大减轻了服务器的压力。
而在后台处理，你以为他们就不麻烦吗，有的比在前台还麻烦，这看语言，毕竟js是动态语言，数据处理相对是简单的。
再说一下你的烦恼，无非就是数据处理麻烦，这关键点还是自身实力问题，这就需要你去提升了，比如基础、算法等，这也是目前前段需要会算法的一个原因。