ps:观点不一定正确,大家就是探讨一下。
我们平时接触各类ajax封装库都会带有超时机制,但像原生的fetch,都是没有请求超时的概念。为什么呢?
用fetch封装ajax请求
function ajaxRequest(url, method, data) {
return fetch(url, {
method: method,
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(data)
})
.then(response => response.json())
.catch(error => console.error('Error:', error));
}
带超时机制的ajax请求
function ajaxRequest(url, method, data, timeout) {
const requestPromise = fetch(url, {
method: method,
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify(data)
});
const timeoutPromise = new Promise((resolve, reject) => {
setTimeout(() => {
reject(new Error('Request timed out'));
}, timeout);
});
return Promise.race([requestPromise, timeoutPromise])
.then(response => response.json())
.catch(error => console.error('Error:', error));
}
1.为什么要设计超时机制
大家可能觉得请求如果没有超时机制,就会一直卡着界面操作。这么想其实没有什么问题,但ajax请求卡多久是由客户端和服务端共同处理的结果,并且大部分是由服务端实际处理业务的时间决定。
假设客户端设置的超时时间是3s,但服务端处理业务的时间就是需要4s,并且无法优化,这种情况,前端的3s超时还有意义吗?
可能有人认为前端触发超时后,abort请求,可以降低服务端的压力,其实并不会,服务端如果不是经过特殊的设计,一旦收到客户端的请求后,就会开始一系列的执行动作,并不会因为客户端连接断开而停止或是结束执行。
2.那就不要设计超时了?
是的,准确来说是不需要前端的超时机制,像fetch这些系统函数的设计,他就是不考虑超时,服务端愿意连多久就多久。
但大家始终还是觉得这样做不靠谱,没有超时机制,我的页面岂不是会很卡。
我的观点是,超时机制还是需要的,但只要服务端控制即可,并且服务端是必需设计超时机制,一方面是保障客户端体验,另外一方面也是保护服务端自身的稳定性,避免卡性能的业务延申到后面的业务,及时结束,当然有些特殊业务可能需要特殊处理,这里说的是大多对接到客户端的请求。
如果大家在开发前就对服务端的接口提出要求,响应时间不能超过1s,那客户端的ajax超时机制是不是显得就很多余,而且要超时多少实际也不是客户端说的算,而是服务端根据自己实际的业务来定。