问就是 graphQL

如果是一个数据的各种枚举的中文映射的场景。是后端不讲理，建议后端按照约定的 schema 一次返回。

如果是两组数据。

如果有多个前端（不是程序员，是客户端），应该更倾向于听后端的。因为不是专门伺候你。
如果仅一个前端，可以以前端开发为主（后端开发是生产者，前端开发是消费者），谁离业务更近，谁说了算，谁责任大。别说帮忙合并数据面向页面提供接口，前端要求后端直接返回渲染好的 html 都行。
但具体实践中大部分要看习惯和交情。


具体情况具体分析吧。




从 op 描述来看。
op 更想省事，后端理由正当合理。



我们要判断争论点是把复杂度和锅（我可以听你的这么做，但是出问题你负责）从谁转移到谁。
争夺复杂度和锅的争论，推脱复杂度但是不甩锅的争论，大部分都是好同志。
推脱复杂度同时也不背锅的争论，我们可以直接理解为队伍里出现了不合适的人。


另外多说一句：
技术团队的技术争论，
如果有人不「站在 “整体”的位置上，看“现在”和“将来”，」
还争个热火朝天，
如果不是公司薪资水平不行。那要么是菜，要么是坏。

也不一定,非要怎么样吧.

具体不知道是一个什么样表格.

不过,就订单或者商品信息.
如果订单信息,一开始只展示粗略信息.(就是一开始,并不会显示所有商品,而是用户点一个详情,然后再显示)
这种情况,我肯定是拒绝一下子,全部返给前端.

其它情况,要商量着看吧.

app 或者大模块首页接口之类的必要性大模块结构可以提供聚合，其他的接口最多提供多批量查询。
接口性能和可靠性是后端负责的话就不可能给你这么提供，不然前后端分离意义在哪不如直接 display ？

看团队 leader 的话语权了。

感觉很多前端都会莫名其妙地追求性能, 前端代码跑在用户的设备上, 成本也不用公司出, 接口慢了也不用前端背锅, 为什么老是要用性能为理由来要求后端改接口呢?

作为后端，如果你要是问我是不是一定要保持单一原则，那我会毫不犹豫的说：是。

但我会依据情况不同改变对单一原则的认定标准（底线灵活）。

单一职责是给内部代码维护用的，不是给外部直接调用的。单一职责的优势是可组合性非常强，代码好维护。但是如果这个接口被外部用了，以后想变就没那么容易了。给外部使用的接口应该首先保证可控，其次才考虑扩展性和灵活性。如果针对外部使用场景专门封装了场景特化接口，这个接口可以随时根据场景调整，内部的单一接口也可以随时按需重构，内部代码的可控性和外部边界都会清晰很多。

视具体业务情况而定

我只会给你开一个聚合接口，不保证后续兼容