Built-in proxy support

[pi0]

Adding as a feature to route rules.

[DamianGlowala]

@pi0, would you be able to give any ETA on this one? 🙏 Would be super useful to have it working in Nuxt 3.

[pi0]

Will work on it ASAP. In the meantime you can use https://www.npmjs.com/package/nuxt-proxy for Nuxt 3 apps only keep in mind some options are probably going to be simplified compating to http-proxy so avoid using options when possible to reduce breaking change chances.

Alternatively you can define a nitro route handler that uses fetch to upstream for proxy effect. This gives full control over headers.

[ironytr]

can't use nuxt3@latest because proxy issues, non module working rn. is nitro proxy ready yet?

[makkarpov]

devProxy doesn't seem to be supporting relative URL in fetch, is this by design? (nitro 0.6.1)

I.e.

// config:
export default defineNuxtConfig({
    nitro: {
        devProxy: {
            '/api/': {
                target: process.env.API_TARGET,
                changeOrigin: true
            }
        }
    }
})

// ======================
// later, on server side:
// ======================

const r = await (await fetch('/api/test')).json();
// => 500 Invalid URL

[pi0]

@makkarpov Yes. You need to pass full URLs because dev proxy is outside of worker and needs to make an actual request.

[frasza]

Any indication when it will be fully implemented?

[makkarpov]

@pi0

Yes. You need to pass full URLs because dev proxy is outside of worker and needs to make an actual request.

But this breaks code unification between client and server. In browser, when I make a /api/xxx request, browser will resolve it to my domain automatically. So it's natural to assume same behavior in SSR context - relative requests should finally end up being proxied. Or resolved to target URLs via proxy config and sent directly to backend.

Otherwise, you either need to add another layer ontop of fetch, or you will end up with a lot of boilerplate for converting URLs to absolute.

[makkarpov]

It's also desirable (but far less annoying) to proxy WebSocket requests for same reason. This time things are even more complicated: you have to invent ad-hoc logic on client. This means, you need to put all your backend paths into a runtimeConfig, check if it's dev or prod, use relative paths on prod (nginx is completely fine with websockets), match correct backend on dev, build an URL.

[pi0]

Web socket layer and runtime proxy support (with direct fetch ability) are on the way :)

[PavlosMac]

Web socket layer and runtime proxy support (with direct fetch ability) are on the way :)

Available yet?

[Arturexe]

Will this be available soon? I can't send auth requests to my backend because of it. Before this is integrated, I can't use Nuxt 3.

[bogumilkorek]

Some ETA would me much appreciated. Our team is also waiting for this.

[paulvonber]

Any news on it?

[MiniDigger]

bumping this every day certainly will not make it faster, plus it annoys everyone who subscribed to this issue for actual updates, so please, just don't.

[scherii]

While you wait, you can follow pi0's earlier advice:
#113 (comment)

In the meantime you can use https://www.npmjs.com/package/nuxt-proxy for Nuxt 3 apps only keep in mind some options are probably going to be simplified compating to http-proxy so avoid using options when possible to reduce breaking change chances.

[michauds]

Commenting here in case this info is useful to anyone. For some reason, I couldn't get vite proxy to match any of the regex I was writing.

After investigation, it seems like all the routes tested by vite are prefixed with __url. This means that if I want to proxy ^/vegetables/.*, I actually need to write the following route in the vite server proxy options: ^/__url/vegetables/.*.

For context, the configured root route on my project is a catch-all, (pages/[...slug].ts).

[pi0]

Runtime proxy support is finally possible via #926 (in nitropack-edge and upcoming 2.1.0 release). Cheers!