跳到主要内容

react-query 管不到 BFF?alova/server 补上重试限流

· 阅读需 4 分钟
Alova Team

你用 react-query 搭了前端,它的缓存和重试让浏览器那边很顺。后来你起了个 Node BFF 调三个下游服务,这些调用的重试和限流都落在服务端,而 react-query 在那儿根本不跑。这篇划清 react-query 的工作止步于哪、alova/server 从哪接手,并给出两侧的代码。

那条线

react-query 活在浏览器里。它的 useQuery 重试、缓存、去重,全都发生在每个浏览器标签页里,绑着 React 的渲染周期。当你的 BFF 调下游时,这些逻辑在 BFF 内部一个都不执行。所以问题不是「react-query 还是 alova」,而是「服务端那层调用归谁管」。

重试:浏览器 vs BFF

react-query 在浏览器里重试一个失败的查询:

useQuery({
queryKey: ['resource', id],
queryFn: () => fetch(`/api/resource/${id}`).then(r => r.json()),
retry: 3,
retryDelay: attempt => Math.min(1000 * 2 ** attempt, 8000)
});

这个重试护的是用户的视图。它对 BFF 出站调下游毫无作用,因为那次调用压根不经过 react-query。

在 BFF 上,alova/server 对出站请求做退避重试:

const { createAlova } = require('alova');
const { axiosRequestAdapter } = require('@alova/adapter-axios');
const { retry } = require('alova/server');

const alovaInst = createAlova({
baseURL: 'https://downstream.internal',
requestAdapter: axiosRequestAdapter()
});

const getResource = (id) =>
retry(alovaInst.Get(`/resource/${id}`), {
retry: 5,
backoff: { delay: 1000, multiplier: 2 }
});

// 在路由 handler 里:
const data = await getResource(req.params.id);

同一个思路,不同层。react-query 管浏览器,retry 管服务端。顺带一句:alova 的客户端 hook 在 uni-app / Taro / 小程序里也能跑同一套 useRequest,所以「浏览器/服务端分层」在内客户端也成立。

限流:只在服务端有

react-query 完全没有「给 BFF 调下游做限流」这个概念,它的 API 里找不到「对服务 X 每秒最多 4 次」这种东西。那是服务端的事,而 alova/server 的 createRateLimiter 正是为它生的:

const { createRateLimiter } = require('alova/server');

const rateLimit = createRateLimiter({ duration: 4000, points: 4 });

app.get('/api/resource/:id', async (req, res) => {
try {
const data = await rateLimit(
retry(alovaInst.Get(`/resource/${req.params.id}`), {
retry: 5,
backoff: { delay: 1000, multiplier: 2 }
}),
{ key: `downstream:${req.params.id}` }
);
res.json(data);
} catch (err) {
res.status(429).json({ error: 'downstream busy, retry later' });
}
});

rateLimit 在请求真正出去之前先扣一个点,被下游打趴的时候它不被你自己的流量埋了。默认存储是 method 的 l2Cache;跨实例时你换成一个共享存储(@alova/psc 或 redis),额度才是真正集群级的。

缓存:先搞清楚它活在哪一侧

这是最容易被混的一点。react-query 的缓存是「每浏览器」的,它不让同一个用户在同一标签页里重复拉同一个资源,但对你 BFF 猛锤一个慢下游毫无作用,因为那次调用不在浏览器里。

alova 的缓存也是客户端策略特性:cacheFor 控制响应保留多久,模式只有 memoryrestore,非 GET 请求默认是 null(不缓存)。在服务端,alova/server 给你的是 retrycreateRateLimiter,它并不顺手塞给你一个下游响应的服务端缓存。如果你不想对重复的慢 GET 反复打下游,得自己加一层缓存(或倚仗下游自己带的),再把 retry/rateLimit 叠上去。

所以分工很干净:react-query 守浏览器缓存,alova/server 守 BFF 出站的重试和限流,互不相踩。

两个工具管的是不同层。请求止步于浏览器的地方用 react-query,BFF 那层交给 alova/server。要完整选型视角,见 react-query 与 alova 对比