feat: add base path to front end

[8de2fdb0]

Small MR adding the ability to serve the hub behind a proxy.

• add docker build arg to set base path frontend is served under
• set vite.config.ts base value based on docker build arg
• update http variant request function to inject base path during calls to /api and /images
• update how static assets are loaded from public folder to inject base path during vite build

To use a base path build the docker image with --build-arg BASE_PATH=/hub/. All assets and api calls from the frontend will use that base path as prefix.

The backend service is not using the base path, when using a proxy the base path has to be stripped.

#1025

Let me know what you think.

[rolznz]

I don't think the changes in this file should be needed - requests always go to /api (this is a special request function to abstract the differences between HTTP and Wails APIs)

[rolznz]

Can we just do:
const BASE_URL = import.meta.env.BASE_URL || "";
args[0] = BASE_URL + args[0];

[8de2fdb0]

I don't think the changes in this file should be needed - requests always go to /api (this is a special request function to abstract the differences between HTTP and Wails APIs)

Running vite build will inject the import.meta.env.BASE_URL to all resources loaded from the server, but not into the API requests, there is probably a better way to have vite modify the API urls from where they are used, but injecting it here seemed simpler then refactoring all the individual api hooks.

I only added it to the platform_specific/http variant since that feature won't make any sense with wails.

Can we just do:
const BASE_URL = import.meta.env.BASE_URL || "";
args[0] = BASE_URL + args[0];

The const import.meta.env.BASE_URL is injected from vite during build, see https://vite.dev/guide/build.html#public-base-path.
Looking at the docs for the specific vite config option it is default set to "/", my changes also added that value in the config in case the env variable BASE_PATH is unset. So it must be always "/" at that point.

About the path concatenation, yes I think so, but it would need to be some kind of path.join so /base_url/ + /api will result in /base_url/api. The slice[1] kind of expects the first char to be / and removes it and since only parameters starting with /api and /images are matched that will always be true. But that will fail in case BASE_URL is /hub.

Best is probably to add a small joinPath function.

[rolznz]

I simplified this in 8de2fdb0#1 and it works from my testing with caddy. Please let me know if that works for you.

One thing to note is you will need to update to use /hub rather than /hub/ for the BASE_PATH.

[rolznz]

there is BASE_PATH and BASE_URL, we only need one, right?

[rolznz]

Currently BASE_URL is an already declared property used by the hub go app.
Also note there is a FRONTEND_URL used by the go app too.

[8de2fdb0]

So BASE_URL is a vite specific, I think they call it URL since they allow to set the whole URL in cases resources come from a specific server (CDN for example). This feature is focused on allowing to server the frontend behind a proxy using sub path. That case is usually named base_path and I wanted to keep the top level variable reflecting that specific use case. URL would suggest to allow to change the whole URL.

I could't see a specific group set up for the /api path in the echo framework boilerplate, and a quick search seems to suggest FRONTEND_URL and BASE_PATH is used when connecting the alby account with the local hub instance ( from default https://getalby.com/).

Yes that has a potential for creating confusion. Maybe the BASE_PATH should be called VITE_FRONTEND_BASE_PATH.
Since you have a better understanding of the already existing variables, do you have any suggestion that helps differentiate ?

And I would really not focus on BASE_URL since it is a vite internal and is a constant injected into the build artefact. Runtime env variables won't reflect on that, it is just build time relevant.

[rolznz]

Thanks for the details, after looking into it I understand this is how vite works. And the FRONTEND_URL we have is somewhat different and only applies to Alby Cloud. So that one can probably be ignored for now.

I made some changes in this PR - could you review?

8de2fdb0#1

[rolznz]

Hi @8de2fdb0 thanks for the PR.

Could you provide a caddy or nginx config or similar that I could use for testing?

[8de2fdb0]

Hi @8de2fdb0 thanks for the PR.

Could you provide a caddy or nginx config or similar that I could use for testing?

Here is a traefik setup, that will make the hub available under http://localhost/hub/.
The hub image is not configured, so you need to add some env variables at least.

services:
  traefik:
    image: traefik:v3.4.1 
    container_name: traefik2
    command:
      - --api.dashboard=true
      - --api.insecure=true # WARNING: Do not use in production without proper security measures
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
      - --log.level=DEBUG # Good for debugging, adjust for production
    ports:
      - "80:80"
      - "8080:8080" # Traefik dashboard http://localhost:8080/dashboard/
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - web

  # serve albyhub under http://localhost/hub/
  my-service:
    image: localhost/getalby_hub:latest
    container_name: getalby_hub
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.my-service.rule=Host(`localhost`) && PathPrefix(`/hub`)"
      - "traefik.http.routers.my-service.entrypoints=web"
      - "traefik.http.services.my-service.loadbalancer.server.port=8080"
      - "traefik.http.middlewares.my-service-stripprefix.stripprefix.prefixes=/hub"
    networks:
      - web

networks:
  web: