ekzhang
Make WebSocket URL relative to path on which RustPad itself is served
The path stays the same in all currently supported scenarios, but this also allows serving the app from a subpath.
Hm, can you give an example of where it would be served on a subpath? Is this something supported by reverse proxies / did it come up for you?
Yes, all reverse proxies I’ve ever used allow adding rules along the lines of forwarding /rustpad/api/* to http://localhost:3000, while serving /rustpad/* from the local file system. It is possible to serve /rustpad/* from the local file system and forwarding /api/* instead, but it clutters the top-level namespace, that in this case would be used by Jitsi Meet with Rustpad being “only” its EtherPad-standin helper service. (I haven’t set this up yet though, since getting the web component to build on NixOS is hard – there is no established way to deal with wasm-pack in that system unfortunately.)
I needed one more patch to make Vite’s build output use relative links, but not everything (all patches) appear to work.
See final version here if you’re curious: https://talk.erin-nachhilfe.schlarb.eu/rustpad/#sD2loh?showSidebar=false&userName=SomeUser
Nice, great stuff. Is there a reason you wouldn't just forward /rustpad/:path to localhost:3000/:path?
@ekzhang: I’m not following unfortunately, why would I forward serving the web client package to the API server?
There are not two separate servers, intended deployment method is just one server for API routes and static files.
That's how the Dockerfile works!
Ok, I never looked at either the Dockerfile nor the rustpad-server code. If I understand the server code correctly it also serves up static files from a local directory named dist/?
I just assumed I need to server static files separately since that is how all server software I know (which is mostly Python) works. In my current deployment scenario the frontend is also built independently from the server component (I managed to build the web and server components in a smart way now, but they end up in two unrelated packages/derivations only sharing the Cargo dependencies), so it doesn’t make much sense to combine the two if one can just define 2 routes in the web server that is already required for TLS termination…
More importantly, this is all besides the point anyways since I could have just written this instead and it would still name the same issue that this patch solves:
All the reverse proxies I’ve ever used allow adding rules along the lines of forwarding
/rustpad/*to http://localhost:3000 (stripping the/rustpadprefix before passing the URL to the backend), thereby allowing a different service to be hosted at/.
Whether static files are served by the web server or the rustpad server isn’t relevant to this issue at all.
server static files separately since that is how all server software I know (which is mostly Python) works
This isn't how the Jupyter server works, for instance. No worries though