Serve Console bundle from Nexus

[david-crespo]

The console is a static JS bundle. For local console dev, we currently spin up Nexus and then proxy API requests to it through the Vite dev server with an /api prefix. When we deploy to GCP for QA and demo purposes, we use nginx to do roughly the same thing. In both cases, something sits in front of both Nexus and the static bundle and serves both.

In production, since it doesn't look like we're going to have a reverse proxy in front of Nexus, we will need to serve the Console's static JS bundle directly from Nexus. This is convenient for authentication because it means we can check if the user is logged in immediately on the initial request for a console page, rather than, e.g., sending down the JS bundle unauthed, trying to render whatever page, and only finding out we need to log in after an API request comes back with a 401 (problem discussed in oxidecomputer/console#501).

Requirements

• Requests to some wildcard route (say /c/* for now) get the console static bundle in response
• Automate building the console and copying static files into the right place
  • This includes the console JS bundle and other assets, as well as a simple HTML login form that should probably also live in the console repo separate from the main bundle
  • We could also manually check in the files but that feels a little weird
• Once we start using auth more fully, the /c/* route handler should have an auth check and redirect to a login form if unauthed

The wildcard route thing might be a placeholder — maybe the way we really we want to do it is with console and api subdomains. Deciding how this works in detail is a good fit for the reworked version of RFD 169 Console Authentication and Session Management.

There's an example of how to serve static files in the Dropshot repo.

[davepacheco]

Sorry if we already discussed this, but would we consider serving this from a separate Dropshot server (still running in Nexus)? Different OpenAPI docs (if any) for the console, could have different a Dropshot context with different configured authn schemes, etc.

[david-crespo]

That would make a lot of sense! The console endpoints (really one wildcard endpoint, plus login I guess?) would probably only support session cookie auth.

[david-crespo]

I also want to note that @zephraph is advocating for the API routes to be behind /api/* and the console routes to be at root. That would certainly be nice for the console user, it does match how I've seen it done elsewhere. In any case we are not trying to make anything like a final decision here.