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

[tourist2018]

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

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

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

[zhang77555]

现在有一个接口返回一个数组,前端把他渲染成一个表格.
1.现在要显示这个表格某个属性值的求和, 谁来处理?
2.没过多久又要显示另一个属性值求平均,谁来处理?
3.这样类似的表格接口有几十个,都有类似要求,谁来处理?
4.还是这类表格数据量基本在固定几十条,本来只在 PC 端展示,突然要求要上 APP 一页展示 10 条,分页谁来处理?
5.表格数据量随时间增长,做分页,谁来处理?

[royzxq]

我觉得都可以，看具体需求。
----- btw block 了某位四字母“大神”，总能发表一些奇奇怪怪的言论。

[Yuicon]

现在前端也越来越复杂了，不再是以前的切图仔了。我认识的前端朋友跟我说的是很多业务逻辑都被前端抢过去做，话语权也不停的上升，搞得我还有点危机感。

[tiedan]

前端只负责展示

[root8080]

感觉还是要分复杂程度吧 但是由于这个度的界限很难定义 就开始互相甩锅了

[tt67wq]

我们的前端因为不会把 timestamp 转字符串跟我吵了一架你敢信？

[czar]

@springz "平白无故"这个结论不知道你是怎么得出来的

[saulshao]

这种事情由谁来干其实就一个标准: 谁花的时间少精力少就由谁干.

[MisakaMikoto]

服务端就是提供服务的，服务目标给谁？客户端呀！

[dk7952638]

就看前后端谁牛逼了，理论来说后端提供统一接口，前端按需对数据进行加工是最合理的

[anan1231230]

这事出来结果请通知我一下 [滑稽]

[npe]

你就惯着他吧

[no1xsyzy]

@AngryMagikarp 所以说问题的根源在于笼统地将所有的 “用户端” 称为 “前端”。
仔细检查就可以发现，twitter.com 是基于 Web 技术的 C/S 模式，我认为叫做 WC/S 模式也并无不可。
这和之前 Viaweb 那时候的真· B/S 模式是显著不同的。
更类似边缘计算了。

你什么时候产生了 GraphQL 只能 CRUD 的错觉？

[sdushn]

后端吧，前端需要考虑版本兼容问题，实现起来确实不难，但是如果规则有改动，就 gg 了

[xfriday]

@royzxq 你 block 了就 block 了，干嘛发给大家看？你在想啥，嗯？

[AngryMagikarp]

@no1xsyzy 这个说法和“是什么让你产生了 JQuery 不能做单页巨型应用的错觉一样。”当然能做，你就是这么牛逼。

GraphQL 只能算一个规范的中间层，但在这个问题上并不解决任何问题，它不能“自动”地按照产品设计要求给出相应格式的数据，中间的转化总得有人去做。那么问题来了，到底谁去做？

不要指望用技术弥补人的愚蠢。以前 restful 刚出的时候也一大堆吹嘘，结果真正能用好的没几个。一个系统的设计必然要考虑到可维护性扩展性等等，不能简单地按照谁方便谁做来定。这就是为什么中国的互联网企业和国外的在专业性上相差这么大的根本原因。

功能都能实现，毕竟还有 996 福报加持，但实现得如何那就是另外一回事了。

另外我是做全栈的，我很清楚客户端是怎么回事。也遇到过很多客户端的开发，总是喜欢把一些很简单的东西夸张化（也许在他们的眼里确实很难），好减轻自己的工作，甚至减少自己的责任。有这种想法的团队，我是很难相信能做出多好的产品的。

我不想扯一些具体的情况，因为情况往往是复杂的，不能在这里说清楚。我强调的是一种工程化规范化的做事方式，绝不是简单的客户端只负责展示，也不是全部客户端自己算那么简单。

但一般会按照服务端的方案走，因为他们往往更清楚具体的数据逻辑关系。很多后端开发并不具备这种能力，那是个人问题。

[no1xsyzy]

@AngryMagikarp jQuery 当然能做好单页巨型应用，并且在恰当的调教下能做得比 Vue 好。模块化、数据驱动、双向绑定，都可以依赖一些插件，但每个都能做到最好。而且对于 Progressive Enhancement 支持更好，比那些一旦自定义元素就直接废了的强。这点上我认为 Svelte （因为标榜自己是编译器所以）本可以做到更好…… 结果没能符合期待。
我还指望编译完成就符合表单交互（为什么会这么指望）

具体到底谁去写，还是 “组织结构决定软件结构”。

我更倾向用技术过滤愚蠢的人…… RESTful 我没能十分钟理解，就说明里面有问题。
最后是这一句让我（感到）完全理解了：“模拟 Unix 文件操作”。那么其优劣就很明显了。Unix 哲学完全看写的人，不然分分钟变 X11，说了等于没说…… 直接做成 HTTP 的 RFC，那就是真的 “什么都没说”
有（明白设计中间层规范的也是经常犯蠢的凡人）这基础，看 GraphQL 的时候就明白很多了。问题也很清晰：比如，多联级容易引入太多重复的数据。Pocket 的接口算是让我直接见识了。因为不信任不同级数据间能保持一致性的关系，我就一直在纠结到底用哪个这一数据。最后还是第二天重构成 dataclass 用 dacite 读取的时候才放弃思考这个问题。

我认为这方面 “工程化规范化的做事方式” 根本不存在。也可能我曾在和现在的组织本来就比较松散有关。
但基本上我觉得这种，要么是架构先拍板，要么就是先随便写，看情况再改。前者在快，后者在可变。
说到底是前后端语言不同的问题，最好是直接传有类型的。为什么要传 timestamp ？直接传 datetime 类型多好？

[icris]

『简单的求和』
1. js 数字运算不精确，不存在简单的求和（
2. 具体应用不了解，如果简单的求和是指数组内属性求和，比如说叫购物车总价，如果后期改动添加分页就不存在前端计算的可能性，服务端计算不正是为了适应复杂多变的需求。

『一个页面如果按前端的说法 可能后端会有 n 多个 API 接口』
不理解，后端聚合只会减少 api

[INFP]

现在的人都是 nt 吗？后端该给什么数据都要发帖来问？