Documentation
¶
Overview ¶
SCOPE:core — Flat-stack boot helpers (demo seed, TOTP key wiring).
SCOPE:core — Flat-stack chi server (the only server)
BootChi / AttachJetStream / Serve compose the flat stack: boot builds everything that needs no engines (DB, auth, handlers, hubs, queues, workers), AttachJetStream installs the cross-instance publisher and consumer once the DagNats-owned NATS is reachable, and Serve binds the listener. cmd/web needs the split: DagNats owns the embedded NATS and must boot before JetStream exists, and the onboarding worker needs the todo handler BootChi returns — one function could not have both. StartChi keeps the single-call shape for frontends whose boot order allows it (cmd/desktop). ChiAddr empty disables the serve path, so a stock env never changes behaviour.
SCOPE:core — static asset + Service Worker mounts (the one serving path).
Split out of chi.go, which is at the file-sizes gate: the core bundle and the Service Worker serving are one subject, and the per-feature mounts stay in chi.go because the installer's trim/add units edit those lines.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func StartChi ¶ added in v0.44.0
func StartChi(cfg *config.Config, js nats.JetStreamLike) (stop func(), err error)
StartChi boots, attaches JetStream and serves in one call — the single-function entry for frontends whose boot order allows it (cmd/desktop: NATS is up before the stack boots). A nil return with a nil error means "seam disabled" (no ChiAddr), so a stock env never changes behaviour. cmd/web uses Boot/Attach/Serve directly: its DagNats engine owns the NATS and must boot first.
Types ¶
type ChiStack ¶ added in v0.44.0
type ChiStack struct {
// TodoHandler is the todo slice handle engines wire against: the
// DagNats onboarding worker creates example todos through it, so
// cmd/web passes this to startDagNats before NATS exists.
TodoHandler *chi.Handler
// contains filtered or unexported fields
}
ChiStack is the booted flat stack, held apart so callers can attach JetStream and serve in the order their boot graph requires. Boot owns DB, auth, handlers, hubs, onboarding, credits, queues and workers — everything that needs no engines. AttachJetStream installs the cross-instance publisher + consumer, which need the NATS the DagNats engine owns and therefore cannot exist at boot time. Serve binds the listener. The zero value is not usable; build with BootChi.
func (*ChiStack) AttachJetStream ¶ added in v0.44.0
func (s *ChiStack) AttachJetStream(ctx context.Context, js nats.JetStreamLike)
AttachJetStream installs the cross-instance wiring on js: the CRUD publisher on the todo handler and the consumer goroutine, which runs until ctx is cancelled. Nil-safe by construction — NewCrudPublisher(nil) yields a nil publisher and RunCrudConsumer no-ops — so a NATS-off boot attaches nil and behaves exactly like the Hub-only stack. Call once.
ctx is the caller's lifetime signal (cmd/web passes its lifecycleCtx; StartChi passes Background) — the stack holds no context of its own.