背景
可能很多人会疑惑,为啥我们都用了服务端渲染框架,还需要用接口代理呢?其实大多数团队,都是前后端分离的架构,已经用 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: {
devProxy: {
"/api": {
target: "http://localhost:3001", // 这里是接口地址
changeOrigin: true,
prependPath: true,
},
},
// 该配置用于服务端请求转发
routeRules: {
'/api/**': {
proxy: 'http://localhost:3001/**'
}
}
},
})
踩坑记录
1. 配置 vite 的代理不生效
从 RC12 开始,vite 的代理配置就不再被支持了。下述配置方法将不再可用。
vite: {
server: {
proxy: {
'/api': {
target: 'http://localhost:8080',
},
},
},
},
2. 服务端请求代理配置不生效
routeRules
中支持配置 proxy 必须要在 Nuxt3.2 版本才能生效, 笔者升级后版本如下:
结语
博客原创地址:Nuxt3实战系列之接口的请求代理配置
欢迎读者朋友们批评指正。
联系作者:imwty2023(微信),iwhitney@163.com(邮箱)
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。