前端后端的各位，接口请求数据的时候，你们更喜欢哪种方式

接口肯定是要写三个的，一次全加载还是切换 tab 时加载前端自己决定

图看不到

@fruitmonster 我这里能看到，画的不错，请问一下用什么工具画的呀

@qiaofanxing https://excalidraw.com/ v 站很多人讲过

@fruitmonster 很简单我描述一下，三个 tab 栏是同时请求数据、还是点击才请求

数据是固定的方式一好点，数据是动态的且希望切 tab 刷新数据就方式二

看需求，切换频率不高的话分三次，前端加个骨架屏切换时显示

显示哪个请求哪个，但原因并不是后端希望这样做。
前端这样做，更符合按需渲染、按需加载。

如果涉及到缓存/重复请求，或者 OP 要求方便调试，应该从其他方向解决问题。

好多国产 app 就是全部加载，妈的流量刺客

也得看看 A\B\C 的数据结构是不是一样的。 不一样的话，全部加载还要做额外 type 判断。

React 的话全部 api 封装成 useDataA, useDataB, useDataC, 用起来也方便。

看场景呗，数据量少的话，聚合在一块加载还是可以接受的，web 只需要请求一次，速度也很快。数据量大的话，肯定是第二个，首次加载的数据量易于控制，而且后期想要做成三个同时加载也不过是在代码里并行请求两次接口而已。

@NathanInMac #9 用户体验起来快啊，至于用户有没有体验就又是另一回事儿了，哈哈

后端性能没瓶颈的话，分开对大家都好。有 http2 在，也不怕浏览器堵请求。前端还能做加载优先级控制，后端也能少写点聚合接口。

不用看评论也知道。
后端：接口要分的越细越好，前端你来组装。
前端：接口要越少越好，只要前端要展示的你都要一次性下发。
阿里：前端同学、后端同学，你们表吵了，这事让中台同学来。

就一个问题，切换 tab 刷不刷新？不刷新怎么保证实时性，刷新又何必

@sakura1988 刷新又何必开始的时候就请求全部数据。

后端写三个接口，前端自己维护个 BFF （ backend-for- frontend ）做接口聚合。

我不是说这是最好的，而是前后端分离之后必要的，我支持全栈。

从用户体验来说选 1 ，就算选 2 也是前端说了算，前端可能同时请求了这 3 个接口

我是后端的话，提供 3 个接口，前端爱怎么写怎么写
我是架构师的话，让前端每次点击一个 tab 的时候再请求新的
缓存、预请求之类的更深入的这里先不讨论

点了再切换，不然压测时候测试搞一堆数据可能影响性能给你来个 bug

那肯定是点哪个请求哪个呀，我理解 op 为什么想要第二种，减少并发是吧哈哈哈。

你要是想让前端按第二种改，可以使劲抓它小辫子，比如你当前在 tab1 ，但是 tab2 页后端更新数据了，切换 tab2 数据没有及时刷新，你就怼前端 tmd 怎么写出 bug 了。前端如果把切换 tab 就请求对应接口写上了，你就怼前端初始进入页面的时候请求三个接口，切换 tab 又请求接口，重复请求，又有 bug ，你们前端 xxxxx 吃的 hhh

一般不是看生命周期么，tab 加载和切换的时候才会取数据。一次性取三个，除非是静态数据

这不仅仅前后端协作的问题，还会涉及到用户体验的问题，如果一下子请求 3 个 tab 的数据，从技术人的角度可能会觉得对用户是友好的，提前准备好数据，能够无缝切换 tab ，但是体验上却未必：
1. 一次请求多个 tab 页的数据会增加服务压力，可能会影响接口性能，降低整体的用户体验
2. 提前加载数据，用户切换 tab 的时候不能及时展示最新的数据
3.没有过度动画会给人一种“假数据/写死的数据”的错觉

综上，个人更倾向于切换 tab 时实时请求当前页的数据。

graphql 按需取可以么，但是需要不被后端挨骂，还需要老板支持

肯定是第二种啊，三个接口，这样数据量也小请求快，如果用户不点 bc ，也不会请求浪费资源

@xuld 中台：这个需求等排期

还有另外一种，初始化只请求第一个，闲时获取其他数据。点击切换时如果该数据未获取，则插队获取对应数据。

想什么呢，必须 3 个接口呀， 职责单一； 前后端分离，3 个接口， 前端按要求自行控制加载逻辑；

我会根据情况写 1-2 个接口,但是一次性加载 3 个 tab 的接口是必须要做的,这样用户体验较好,没有卡顿不需要等待

首先看这个 tab 是否永远都是这 3 个会不会变成 456 个.
第二看这些 tab 是否会分页.

如果不分页的话直接一个接口完事,有分页就写两个接口. 1. 获取首页 tab 预览信息(即所有 tab 的前 10-20 个记录)
2. 获取某个分类 tab 的分页数据

主要是考虑用户体验，并不太会影响调试。既然考虑 1 ，大概率数据不需要及时更新。在这个前提下 1 的体验好一点，请求 1 次； 2 查看了 3 个 Tab 的时候请求了 3 次。
还要考虑场景，切换 Tab 的概率大不大。
综合我建议 2 ，接口更清晰，能避免第一次加载过多数据，Tab loading 问题不大。2 对前端要求更高一点。
而且如果做数据缓存，只有第一次请求的差别。

接口都写，然后根据用户习惯在前端进行预加载，能保证请求干净，并且前端体验不会很糟糕。

@xuld 中台这个鬼东西真的是比微服务还玄学

@blackmatch 肯定要点击后刷新，但是你没说到重点，因为你在上滑肯定有加载分页的，就这一条，就得让他实时刷新

肯定是 2 ，这是最基础的设计原则。每个接口要做专一的事，除非页面出现频繁调用接口。
举个例子，那么以后出现一个其他的单独的页面只要 A 页的数据，那怎么办，第一种方法的话会有大量的性能损失，更何况是无关的数据

菜逼前端 我开始是 2 测试切 tab 感觉体验不好 叫我改成 1 了（一次性请求多个 tab 的接口 虽然不是一个接口）
数据实时性在我这个 case 不是问题，因为都是用户导入的数据，而且用户登录只能单点登录，导入之后刷新对应 tab 就行

@Rennen 为什么写 3 个，一个传不同的 tabId 不行吗

后端提供：
GET api.com/list?id=xxx ，不传 ID 加载全部

前端看具体需求和业务情况选择怎么用