In reply to @k900:0upti.me
Looks reasonable enough, but also, why?

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)

In reply to @luke:vuksta.com

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)