In reply to @k900:0upti.me
That's a lot of assumptions

I didn’t think I’d need to tell anyone not to expose their manufactuing machinary to the public internet 😆

But yeah, the same setup could be performed with DNS, but clearly there are users that serve it at a subpath instead - Moonraker or Fluidd would not support this otherwise? I imagine the subpath could be simpler to manage from an infrastructure configuration perspective, which might be the reason it exists at all

It is a fairly uncommon setup (because most people with printers tend not to go about using a domain at all from my time in the 3D printing community), but some people like myself end up exposing these machines under a subpath that only gets served if the request comes from behind a VPN subnet. If you have many machines, like a print farm, you would also benefit from this sort of setup - easier to serve at a subpath than manage a ton of DNS entries for subdomains etc.

But if you mean, “why do Moonraker and the web interface share a domain?” That seems to be the default configuration already for the most part, given that Moonraker gets served at “/websocket” as this combination of apps usually runs from the same SBC and is tightly coupled to control a 3D printer running Klipper.

The pattern for these printers is as follows:

1. Klipper opens a unix socket that acts as its API endpoint
2. Moonraker interacts with that API socket to control Klipper, and exposes a websocket.
3. Web frontends like Fluidd or Mainsail interact with the Moonraker websocket for user control via a GUI (nobody is running their printer directly from API calls to Moonraker)

proper resolver

oof