EezoApp

What dev serves. The umbrella overrides it to run the drift check first and serve the drift page when the check blocks.

The http layer's boot under the database layer's lifecycle: the one line the compiler makes this trait write.

Origins other than the server's own whose pages may open a live socket, each written scheme://host or scheme://host:port. Empty by default, because the page and its socket come from the same server unless something in between rewrites the Host the browser asked for. That something is usually a proxy, and forwarding the browser's Host is the better fix; this list is for when it cannot. Matching is exact, with no wildcard, since a pattern that admits a subdomain admits whoever controls that subdomain. An entry that is not an origin fails the boot.

The application. The default serves routes on port, which is what makes the minimal application one override and nothing else. Override it for anything more: background work, another setup, no server at all.

The commands this application answers, as first argument :: rest. Nil is program and is answered here, once, so no layer owns it. Each layer writes own orElse super.commands for its own commands, so the later mixin's arms are consulted first.

Short on purpose. detached borrows a second connection while the caller still holds its first, so one thread can hold two, and a full pool can deadlock on itself; the timeout is the only thing that turns that into an error. HikariCP's own 30 seconds reads as a hang to whoever is waiting on the request, and a request that cannot get a connection in 5 seconds is better answered with a 500 than left open.

Run on every connection the pool creates, not once on a borrowed one (DESIGN §8.7).

This is where search_path, application_name and statement timeouts belong. Without it an application that works in a non-public schema silently splits in two: its own connections see one schema and eezo's see another, which shows up as a migration that appears not to have run.

Small on purpose. HikariCP's sizing rule is connections = cores * 2 + spindles, because Postgres does its work on CPU and disk, and connections beyond what those can serve only queue inside the database instead of in the pool, where queueing is cheaper. Virtual threads make requests cheap, not connections: thousands of requests waiting briefly on a small saturated pool is the intended shape, not a sign the pool is too small.

The Postgres schema the drift commands introspect. search_path is set per connection in databaseInit; this is the same name, told to the side that reads catalogs.

Overridable, so a test or a second environment can point elsewhere without touching boot.

Routes the framework itself contributes, appended to whatever table serve is given so that every caller — boot's default, a user's own serve in an overridden boot, dev — serves them without knowing they exist. Empty here: eezo-live's LiveApp overrides it with the live socket and its client script, and EezoApp mixes that in. Appended, so the user's table keeps winning any path both name; they show in the boot listing (they are served, and the listing does not lie) but not in eezo routes, which is the user's table.

The frame every HTML reply comes back in, the derived pages, the login page and the error page included. eezo's plain one unless the application names its own here, which is the one place a frame can be chosen, so that no route has to remember to ask for it.

The request body cap, and the WebSocket text message cap with it.

What help says after the command table and before its footer: the caveats that belong to no single row. Each layer writes own ++ super.notes, and they are kept apart from usage so a stacked application prints one table and then every layer's notes, rather than one layer's notes in the middle of the other's commands.

Where boot's default and the dev command serve.

How the application's own failures are answered: a partial function from what a handler threw to the problem the client sees. What it does not cover, the boundary answers as 500.

The key the session cookie is signed with. EEZO_SECRET by default. The sbt plugin's dev loop sets it to one secret per sbt session, so a restart on edit keeps the developer signed in. A run outside that loop with nothing set gets a throwaway announced at WARNING, so that hello runs with no configuration and a deployment that forgot is told. Read once, when serve boots.

The only caller of HttpServer.run: boots the server on this trait's overrides and blocks until it stops. dev turns the listing and the reload client on.

One row per command, for help. Each layer writes own ++ super.usage, and names only the spelling and the description: the columns are help's to lay out, once, over every layer's rows together, so no layer has to guess how wide the others' spellings are.

The lifecycle, scoped to one command: built, installed, closed. Final, and protected rather than private so the umbrella can wrap the dev server in it.

The route table, usually Routes.table() from the sbt plugin's generated object. Abstract: an http layer is its routes, and an application without any is a mistake.

The application's schema, object AppSchema extends Schema named here. Abstract: a database layer is its schema, and an application without one is a mistake.