Reverse proxy support

[andrei-vintila]

trafficstars

Basically add support for what is mentioned here. By default it should be off as it will basically take all the posthog trafic and route it through the server that hosts nuxt.

[mitjans]

Hi @andrei-vintila, thank you for your suggestion, it could bring value to this module.

I'll gladly work on it starting next week, sorry for the delay 🙏

[hacknug]

I have a PoC for these changes but I believe there is some API discussion we should have before finishing any implementation.

We can already reverse proxy requests for the module using the following options in nuxt.config.ts:

routeRules: {
  '/ingest/ph/static/**': { proxy: 'https://eu-assets.i.posthog.com/static/**' },
  '/ingest/ph/**': { proxy: 'https://eu.posthog.com/**' },
},
posthog: {
  host: `${isDev ? 'http://localhost:3000' : process.env.URL}/ingest/ph`,
},

[!NOTE] I don't like using a generic /ingest/** as the route since I use this same pattern for other analytics/marketing services, hence my preference for /ingest/ph/**

Given PostHog can be cloud-hosted in two regions (us and eu) and also self-hosted, I believe there's little or no assumptions we can make for what those target proxy URLs will be.

• We could add ModuleOptions.region as string to build those cloud-hosted URLs but this wouldn't solve the issue for self-hosted users.
• We could allow users to pass in an object with the routeRules but by then, how much value does the module provide in this regard?

Not sure how y'all envisioning this but I believe this second approach might be the best to account for customization of those rules and keep the module's codebase as simple as possible.

It wouldn't do much but at least you'd be able to keep all your PostHog config in one place (vs routeRules + posthog in the config file).

[andrei-vintila]

@hacknug Good notes. Didn't consider the self-hosting use-case. I think that when you are self-hosting you kinda are already solving the issue that reverse proxy is trying to solve, meaning have a way that to "hide" this traffic under your own domain so that it is not blocked by uOrigin and similar trackers. So maybe we don't need to solve the self-hosting use-case.

In my opinion, the biggest time saver is to figure out what is the base url in a way that works in all nitro deployment options.

Option 1 with region where we infer the values sounds like the easiest way to do it. If this is not covering a use-case you can always disable the feature in the module and just add your own routeRules.

I don't like using a generic /ingest/** as the route since I use this same pattern for other analytics/marketing services, hence my preference for /ingest/ph/**

I agree /ph/ is a better option here.

[hacknug]

@hacknug Good notes. Didn't consider the self-hosting use-case. I think that when you are self-hosting you kinda are already solving the issue that reverse proxy is trying to solve, meaning have a way that to "hide" this traffic under your own domain so that it is not blocked by uOrigin and similar trackers. So maybe we don't need to solve the self-hosting use-case.

It's possible but I wouldn't assume adblockers won't ever block based on the URL. Self-hosted users might have their instance under posthog.example.com. In this case it might be helpful?

If this is not covering a use-case you can always disable the feature in the module and just add your own routeRules.

This is also true and I don't dislike the idea given everything else I mentioned.

I agree /ph/ is a better option here.

Awesome! Let's wait to hear from Carles 👍

[mitjans]

I agree it would be best if we provide some out-of-box solution to cover most cases. The idea of this module is to make the development process as easy and frictionless as possible. If the user wants to customize the behavior he would always be able to disable the default proxy and create his own using routeRules.

What do you think of the following:

export default defineNuxtConfig({
	posthog: {
		proxy: {
			enabled: boolean,
			region: string,
		},
	},
});

Internally, we would:

// Client bootsrap
if (config.proxy.enabled) {
  clientOptions.api_host = `${isDev ? 'http://localhost:3000' : process.env.URL}/ingest/ph`;
  clientOptions.ui_host = `https://${config.proxy.region}.posthog.com`;
}

// Module setup
if (options.proxy.enabled) {
  nuxt.options.routeRules = defu(nuxt.options.routeRules, {
    '/ingest/ph/static/**': { proxy: `https://${options.proxy.region}-assets.i.posthog.com/static/**` },
    '/ingest/ph/**': { proxy: `https://${options.proxy.region}.i.posthog.com/**` },
  });
}

Not sure about having enabled and region options. Could create unexpected results if the user only adds enabled but not region, or vice-versa. If you have a better idea, more than welcome!

[davidstackio]

Not sure about having enabled and region options. Could create unexpected results if the user only adds enabled but not region, or vice-versa. If you have a better idea, more than welcome!

What about just calling it proxyRegion (or proxy.region)? It can be an empty string by default, and if it's not supplied, the proxy is disabled.

[kogratte]

Hello there! Any news re. this topic? I'm facing the exact same issue where calls are blocked by blocker, and was expected reverse proxy out of the box.

[mitjans]

I've set up a PR with a workaround for the reverse proxy. Would appreciate anyone testing it to make sure it's working as intended before merging..