后端给前端应该提供什么样的数据？

[tourist2018]

这几天和前端同事对接，遇到一些分歧。 前端同学认为我应该把页面每项数据都用 API 直接返回，前端拿到的就是直接可用的。 我认为我提供一些基础数据就可以了，除非特别复杂的逻辑，前端可以通过一些简单的计算得到自己的要求（计算量并不大，我看了下就是简单的求和之类的）。

因为前端的需求比较复杂多变，我在了解需求的情况下，提供现阶段基础数据就可以，具体怎么计算由前端负责。大家觉得呢？（惭愧之前虽然是后端，但一直做 infra 的工作，没有怎么做过 API 方面的对接）

备注： 一个页面如果按前端的说法 可能后端会有 n 多个 API 接口 目前暂时使用前端做法

[tourist2018]

目前我这边妥协了

[jamesxu]

看情况，我这一般直接后台返回，前端直接显示，因为如果还有 app 或其他应用调用的话，每个应用都得写一遍

[tourist2018]

@jamesxu #2 没有 app 只有前端调用 而且是单一的

[springz]

只提供基础数据，前端要是觉得不合适，我可以把 Model 层给他们写了。再撕就不需要前端了。

[springz]

后端计算成本非常高，平白无故增加计算和 IO 开销

[672795574]

我是后端，认为放在后端好一些。
说一个点：需求改动，涉及 APP，小程序发版本。后端效率要高于前端。

[chenzheyu]

json 格式啊，复杂度看心情跟工期，后端忙不过来就简单点，很闲就顺手做点修饰呗

[oddisland]

按照你说的情况来看，我觉得前端做简单计算更好。
但是一般还是后端直接返回结果，前端做展示更为妥当吧。

[no1xsyzy]

@springz 给你们公司推荐一下 GraphQL，你可以失业了

[fffang]

没什么特殊情况的话，能后端做的一律后端做。

[xxx749]

我，前端，基础数据

[ArtIsPatrick]

前端都是被你们惯坏的，后端怎么会帮前端写聚合转换逻辑？不知道怎么写就按标准来，RESTful 和 GraphQL 二选一，你这种情况 GraphQL 可以完美解决。实在不行就在后端加一个聚合层，专门做接口聚合，还能顺便做点网关的功能。

[no1xsyzy]

按标准的 “前端” “后端” 叫法分，就是后端提供数据，前端提供显示。

请其他分法不要叫前后端：
1、把 B/S 写成类 C/S 的，包括 SPA 请求生数据客户端计算的 —— 请叫 WC/S （ Web Client/Server ）；
2、用 WebSocket、高频轮询 等实现前后端同步的，请叫 WebUI ；
3、强行把接口设计不良的服务器套层 Web 变成用户友好的，请叫 Wrapper ；
4、欢迎补充……

当然具体用哪种可以自由选择，组织结构决定软件结构。

[orzorzorzorz]

一些典型的数据结构还是提供下吧，比如说行政区划树。前端渲染的时候还是得把扁平化的数据递归嵌套或者做类似的操作，这就很难受了
还有一个，一般而言，针对小厂的话，后端其实要干的事大多数是对业务跟设计库表，后端们会给前端写个通用的接口，然后给个部署方法让前端自己去写 sql。比如 /api/data?key=xxx，前端到指定资源文件里写 sql，接口返回的查询数据。一般这样会积累不少通用的脚本，只有一些个性化很强的接口才会让后端去写

[no1xsyzy]

还有一个就是 RESTful 要让 Web 端计算的话做好打不开的准备。
一堆小请求直接阻塞，反正浏览器限制同域名同时 6 请求。

[DOLLOR]

太基础的数据，别人拿来就可以猜出你的数据库结构，做攻击尝试了

[no1xsyzy]

@orzorzorzorz 你说的这个，不就是自己造了个 GraphQL ？

[337136897]

我是个后端抛开所有其他不说，我认为后端直接把所有逻辑计算好返回给前端就行了。前端请求接口拿到数据直接渲染就行。无非就是服务器压力大一点。没必要把计算性能都分发到每个用户的手机上。手机越用越卡是有原因的，都各种各样的计算，耗费手机 CPU 性能。让用户多点体验不行咩

[nyaapass]

辣个男人可能不会来了

[starsriver]

简洁，充分，明了，优雅