Feature request: Include a REMIX_DEV_CLIENT_WS_PORT .env variable to better facilitate proxied remix apps. about indie-stack

[laurencefass]

Ive just installed a Vite app and it solves this very problem by providing an HMR configuration which splits the clientport and serverport to enable proxying. a 443 client port works with wss, and any port works for the backend,

https://vitejs.dev/config/#server-hmr

[laurencefass]

I have got this working on port 443 with following configuration.

Using port 443 ensures that the socket port is not explicitly included in the wss:// URL callback from client to server for livereload. Any other port number forces inclusion of the port in the wss URL and breaks proxy addressing. I think 443 is the correct port selection visibile to the client, but using port 443 on the server will cause problems in a multi-instance execution environment. Hence the need to split them.

.env

REMIX_DEV_SERVER_WS_PORT=443

and nginx config:

server {
    listen 80;
    server_name remix1.syntapse.co.uk;
    location / {
        proxy_pass http://0.0.0.0:3300;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
    location /socket {
        proxy_pass http://0.0.0.0:443;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
    }
}

however I expect to run into problems if I try to run multiple instances within a single execution environment so the requirement for a REMIX_DEV_CLIENT_WS_PORT .env var is still viable.

[kentcdodds]

Hi @laurencefass,

Sorry for not getting to this sooner. I'd say that this is a good use case for forking the stack and making your own. Proxying an app is not common enough for this stack's audience to include in this stack.

[laurencefass]

Thanks for replying. Currently I include myself in this stack's audience and Im trying to use it behind a reverse proxy. Other React frameworks I've trialled (Next, CRA, Vite, Blitz) offer a built-in solution for this use case. Can you elaborate why you dont expect reverse proxying remix apps to access on the web to be a common use case?

[kentcdodds]

There are three things at play here:

1. Everyone has different requirements, constraints, and opinions on how they want to build their apps
2. Everything we add to the stack is cognitive load for people who use the stack
3. It's very easy to make a custom stack

So even though there are lots of people who do use reverse proxy, most wouldn't need it, so I'd rather just leave that to the people who do need it.