feat(infra): move backend url from build time to runtime #54

New issue

Closed

opened 2026-01-28 20:57:10 +00:00 by chartgerink · 2 comments

chartgerink commented

2026-01-28 20:57:10 +00:00

Owner

Currently, the backend is baked in on build time (either manual build or docker build).

This makes especially the docker image less valuable, as it is not portable from one to the other backend. It even makes it strenuous in the situation of testing etc, as each has to have their own docker image.

It would be great if we could find a way to make it work in runtime, such that it is portable. It would even be sufficient if we could simply know it is always on the /api path for the origin of the frontend (for example, https://researchequals.com -> /api and https://test.researchequals.com -> /api)

Currently, the backend is baked in on build time (either manual build or docker build). This makes especially the docker image less valuable, as it is not portable from one to the other backend. It even makes it strenuous in the situation of testing etc, as each has to have their own docker image. It would be great if we could find a way to make it work in runtime, such that it is portable. It would even be sufficient if we could simply know it is always on the `/api` path for the origin of the frontend (for example, `https://researchequals.com` -> `/api` and `https://test.researchequals.com` -> `/api`)

chartgerink commented

2026-03-16 19:18:48 +00:00

Author

Owner

It seems like we are already handling the API redirection in the reverse proxy level 😅

researchequals.com {
  redir /api /api/
  handle_path /api/* {
    reverse_proxy xxx.xxx.x.xxx:8080
  }

and we can do the same in the vite config for local development:

vite: {
    server: {
      proxy: {
        "/api": {
          target: process.env.BACKEND_URL ?? "http://localhost:3000",
          rewrite: (path) => path.replace(/^\/api/, ""),
        },
      },
    },
  },

By replacing the backend urls to be relative (eg /api/files/<key>) it would immediately land in the right place because the reverse proxy manages it lands in the correct place. Vite already acts as reverse proxy in the local development space. Only the server side would need to still have the api variable, which can then be run in the process environment.

It seems like we are already handling the API redirection in the reverse proxy level 😅 ``` researchequals.com { redir /api /api/ handle_path /api/* { reverse_proxy xxx.xxx.x.xxx:8080 } ``` and we can do the same in the vite config for local development: ``` vite: { server: { proxy: { "/api": { target: process.env.BACKEND_URL ?? "http://localhost:3000", rewrite: (path) => path.replace(/^\/api/, ""), }, }, }, }, ``` By replacing the backend urls to be relative (eg `/api/files/<key>`) it would immediately land in the right place because the reverse proxy manages it lands in the correct place. Vite already acts as reverse proxy in the local development space. Only the server side would need to still have the api variable, which can then be run in the process environment.

chartgerink referenced this issue from a commit

2026-03-16 20:33:33 +00:00

refactor(client): implement relative client side requests

chartgerink commented

2026-03-16 20:38:37 +00:00

Author

Owner

okay great – the client side components are now using relative paths, which gets captured by the reverse proxy (also covered in the vite setup for local development).

server side rendering is NOT yet covered and is a breaking change, so will have to be reserved for the next major release. There are some quirks that I figured out and I am able to confirm it can work in practice ✅ Please note the following

Core change

import.meta.env.PUBLIC_API_BASE becomes process.env.PUBLIC_API_BASE

Local development

In order to properly test this:

All environment variables need to use host.docker.internal instead of localhost, given that localhost would refer to within the Docker container, which is incorrect. host.docker.internal is the machine itself.
Ensure the deployment works by building the Dockerfile and testing it (remove the build time env variables)

Deployment

Check all variables are present in the runtime environment before redeploying

okay great – the client side components are now using relative paths, which gets captured by the reverse proxy (also covered in the vite setup for local development). server side rendering is NOT yet covered and is a breaking change, so will have to be reserved for the next major release. There are some quirks that I figured out and I am able to confirm it can work in practice ✅ Please note the following ### Core change `import.meta.env.PUBLIC_API_BASE` becomes `process.env.PUBLIC_API_BASE` ### Local development In order to properly test this: - All environment variables need to use `host.docker.internal` instead of `localhost`, given that `localhost` would refer to **within** the Docker container, which is incorrect. `host.docker.internal` is the machine itself. - [ ] Ensure the deployment works by building the Dockerfile and testing it (remove the build time env variables) ### Deployment - Check all variables are present in the runtime environment before redeploying

chartgerink added the

MAJOR

label

2026-03-16 20:42:10 +00:00

chartgerink referenced this issue from a commit

2026-03-17 09:33:48 +00:00

refactor(ssr): move variables from build time to runtime

chartgerink

2026-03-17 09:33:48 +00:00