Remix + Reverse Proxy + Dynamic Basename

[wesleygrimes]

Hi there,

We are building a white-label e-commerce product with Remix -- so far it has really been a breeze to build out with.

Unfortunately, we are running into a major roadblock in moving forward with our first release.

Most of our partners have a WordPress or similar CMS with a domain like: https://coolstuff.com. Our product needs to be proxied from https://coolstuff.com/shop for example to our multi-tenant Remix site. This allows our partners to continue to use their existing CMS solution while "outsourcing" e-commerce to our product.

We have an existing client-side solution in place with a typical React (remix-run/router) application and we are able to dynamically set basename and proxy through from a path that is something other than /. But as you know, client-side rendered only takes us so far with perf and seo, so we really want to lean into SSR.

We were hoping to do that with Remix, but after a fair amount of research, searching through Discord and here on Github, I am not seeing a viable solution. I've looked into @kiliman solution with remix-mount-routes but that assumes we know the basename at build time, which we do not.

I have experimented with patch-package to support passing in a basename into RemixServer and RemixBrowser and then utilizing it at runtime, however, it's becoming increasingly difficult to keep up with new versions as the Remix product marches toward v2.

Are there any plans to support something like this, or does anyone have any thoughts or solutions on how we might accomplish this?

I will try and put up a minimal repo with an example docker nginx reverse proxy showing what we are doing if that will help.

Here is a reproduction with a docker nginx reverse proxy that runs automatically with npm run dev. You can browse to it at http://localhost:8000/shop. Repo: https://github.com/wesleygrimes/remix-proxy-basename

Thanks!
Wes

[kiliman]

Hi. Yeah if you can provide a simple repo, I'll see what I can do to help with your use case.

Never mind. I see you added a link.

I'll keep you posted.

[wesleygrimes]

I really appreciate you digging into this. Happy to hop on Zoom too if you want.

[kiliman]

Ok, I've pushed my changes here: https://github.com/kiliman/remix-proxy-basename

The README explains the process, and I've also commented on the commits.

Let me know if you have any questions.

I'm still not 100% sure about the "cookie" thing, but it is supported via loader context.

[wesleygrimes]

I am reviewing it now, thanks!

[kiliman]

I think that instead of using cookies for setting basename, you should configure nginx to set a header that Remix uses.

I never understood the need for cookies, as the basename is a server concern and not something the client should tell the server, which is what cookies are. The nice thing about the header is that it's only added by the proxy->remix path, so the client doesn't even know (or care).

# nginx.conf
server {
  listen 8000;

  location /shop {
    proxy_set_header x-remix-basename "/shop";
    proxy_pass http://host.docker.internal:3000/shop;
  }
  location /__remix__ {
    proxy_pass http://host.docker.internal:3000/__remix__;
  }
  location / {
    proxy_set_header x-remix-basename "/shop";
    proxy_pass http://host.docker.internal:3001/;
  }

  error_page 500 502 503 504 /50x.html;
  location = /50x.html {
    root /usr/share/nginx/html;
  }
}

This way, the only thing that needs to be generated per client is this nginx.conf file. You'll be able to share the Remix instance.

To verify that everything still works, I created an npm script update-basename so you can change the basename, and it will generate a new nginx.conf file. Restart Docker and refresh the browser, and you'll see that the links work correctly with the new basename.

You can even go back to Remix App Server vs. Express since you won't need to access the context, but instead, get the header directly in your root loader.

// root.tsx

export async function loader({ request }: LoaderArgs) {
  const basename = request.headers.get('x-remix-basename');
  invariant(basename, 'Missing basename header');
  return json({ basename });
}

I've pushed these changes to my fork.

[wesleygrimes]

Been playing around last night and this morning and I totally agree, before I saw you post this I had went with a header only solution. The only reason I did cookies prior was I thought I had to set the basename on the patched RemixBrowser. But by using the dynamic $basename+ route param and making it a requirement to proxy __remix__ through for assets, that become unnecessary. Cookies are definitely a pain in the butt and headers are more straightforward.

I'm pairing with my coworker this morning to see if we can get it working e2e but I think it will.

Thank you so much. I will report back.

[wesleygrimes]

OK, it worked! This has been a huge help @kiliman, much appreciated. Let me know what I owe you haha.

[wesleygrimes]

Sounds like it could be a good blog post.

[shainegordon]

Thanks @kiliman and @wesleygrimes

This seems like an obvious required feature in remix.

But by using https://github.com/kiliman/remix-proxy-basename, I have this solved too.

The only change I made, was to use an environment variable to determine the path, instead of a header.