背景
可能很多人会纳闷,为啥咱们都用了服务端渲染框架,还须要用接口代理呢?其实大多数团队,都是前后端拆散的架构,曾经用 Java 或者其余后端语言开发并部署好了接口服务。这种状况下,咱们天然只须要将前端的申请通过代理转发给服务端的 server
就好了。Nuxt3 中提供的 useFetch 办法封装了很多网络申请的细节,不过该办法会因为渲染模式的不同在应用上也存在着一些差别。上面笔者就将会讲述如何在各种状况下为 useFetch 办法配置申请的代理。
如何配置?
1. 渲染模式为客户端渲染时
Nuxt3 最新的正式版应用了 nitro
做为 dev server, 在其官网文档中,有阐明如何配置代理:
{
devProxy: {
'/proxy/test': 'http://localhost:3001',
'/proxy/example': {target: 'https://example.com', changeOrigin: true}
}
}
咱们须要将该配置代理的选项搁置到 nuxt.config.ts 文件的 nitro 选项中,如下:
export default defineNuxtConfig({
// ...other setting
server: false, // 不开启服务端渲染
nitro: {
devProxy: {
"/api": {
target: "http://localhost:3001", // 这里是接口地址
changeOrigin: true,
prependPath: true,
},
},
},
});
该形式针对服务端渲染的场景也能失效,然而仅会针对产生在客户端测的申请进行代理。比方设置了 server: false
或者因为一些交互行为而触发的网络申请。
const {data: userinfo} = await useFetch("/api/userinfo", {server: false,});
2. 渲染模式为服务端渲染或者预渲染时
当咱们必须得在服务端进行渲染且也须要对服务端的申请进行代理转发的话,上述办法配置是不可行的。笔者寻遍全网,发现很多解决方案是装置一些 Nodejs
的第三方库去实现接口代理的。其实没有必要,笔者在 nitro
的官网文档中找到了计划,即配置 routeRules
参数。
export default defineNuxtConfig({
// ...other setting
server: true // 开启服务端渲染或者预渲染
nitro: {
// 该配置对服务端和客户端都失效,配置了 routeRules 后,就不须要配置 devProxy 了
routeRules: {
'/api/**': {proxy: 'http://localhost:3001/**'}
}
},
})
踩坑记录
1. 配置 vite 的代理不失效
从 RC12 开始,vite 的代理配置就不再被反对了。下述配置办法将不再可用。
vite: {
server: {
proxy: {
'/api': {target: 'http://localhost:8080',},
},
},
},
2. 服务端申请代理配置不失效
routeRules
中反对配置 proxy 必须要在 Nuxt3.2 版本能力失效, 笔者降级后版本如下:
结语
博客原创地址:Nuxt3 实战系列之接口的申请代理配置
欢送读者敌人们批评指正。
分割作者:whitney1289(微信),iwhitney@163.com(邮箱)