Achieving this is rather tricky due to the nature of our multi-page
project. We need to solve several problems:
1. We want a single npm project that produces two independent bundles.
2. We want our paths to be relative to the serving URL, that is `localhost:3000`
in development and in production, whereever the backend is hosted.
3. We have independent backends, hence requiring different `server.proxy`
configurations.
We solve (1) by using vite (already prior to this commit).
To solve (2), we simply remove all absolute URLs from the code and replace
them with absolute paths which will be relative to the serving host.
This creates a problem: Prior to this patch, we only have one devServer running
that would serve both frontends under a different sub-directory (/maker and /taker).
Even though this worked, it was impossible to create a proxy configuration that would:
- Forward API requests from `/maker` to `localhost:8001`
- Forward API requests from `/taker` to `localhost:8000`
Because in both cases, the API requests would simply start with `/api`, making
them indistinguishable from each other.
To solve this problem, we needed to serve each frontend separately. Doing so
would allow us to have dedicated proxy server configurations and forward the
requests to `/api` to the correct backend.
Unfortunately, the intuitive approach of solving this (have a `maker.html` and
`taker.html` file) does not work. With React being a client-side routing framework,
full page-reloads would be broken with this approach because they would be looking
for an `index.html` file which doesn't exist.
To work around this issue, our final solution is:
1. Use a dynamic ID to reference the desired app from within the `index.html`: `__app__`
2. Use a vite plugin to resolve this ID to the file in question: `maker.tsx` or `taker.tsx`
Fixes#6.
By doing a single `cargo build` ahead of time, we are creating all
necessary binaries at once. This allows our cache to work for tests
as well as the binaries.
There is also no need to use release binaries for the smoke test.
Building debug binaries is a lot faster and serves the same purpose:
Checking whether the application actually starts up.
Philipp Hoenisch
Thomas Eizinger
dependabot[bot]
Daniel Karzel