Coffee Server: Module 5

Module 5

Moo — short jobs & how the stack fits

Moo is the Wire / jobs lane: short, bounded work — invoke a allowlisted plugin, get JSON back, enforce a timeout, keep plugin code off the main HTTP loop (worker thread today; child “moo-car” planned). Think Lambda- or Edge-shaped, except the CPU is yours and policy is Keyman-aware when exposed.

Registry, not arbitrary code

Plugins are listed in registry.json — ids are allowlisted; the server does not require() user-supplied paths. That is the controlled version of “serverless” where anyone could upload a handler: here, only operators extend the registry.

GET /api/moo/registry exposes public metadata; POST /api/moo/invoke accepts { "plugin", "params" }. Browser helper: coffee.moo in moo-request.js.

Why timeouts matter

Every invoke gets a capped runtime. In the real world, runaway jobs exhaust memory and freeze APIs; Moo’s design bakes in failure boundaries early. v2+ may add queues and job IDs — same story as graduating from sync invokes to SQS-shaped patterns.

Assembly recap

Request path sketch (simplified):

  1. HTTP hits main (Express).
  2. Keyman middleware decides if the caller may proceed.
  3. Vault operations proxy through IPC to the vault sidecar.
  4. Moo runs allowlisted plugins in a worker, not inline in the route handler.
  5. Other sidecars (workspace, DB, …) follow the same spawn + proxy idea.

SERVER-DEMO is the guided tour of these pieces in one dashboard; the names above are the vocabulary you will see in settings and status panels.

Whole course recap

  1. Module 1 — Coordinator process, owning the crib, POC surfaces.
  2. Module 2 — Vault + IPC + init ritual.
  3. Module 3 — Keyman gates and tokens.
  4. Module 4 — Sidecars as long-lived services.
  5. Module 5 — Moo for burst jobs + stack picture.

Pair with Home Cloud for LAN, backups, and exposure — Coffee Server is what you might run on that LAN.

Moo POC (MOO1) SERVER-DEMO