boatramp_node/lib.rs
1//! Node assembly for boatramp.
2//!
3//! The `boatramp` binary was historically the only place that turned parsed
4//! configuration into a running node (store + backends + handler runtime +
5//! reconcile loops + router). That assembly is not reachable as a library, so an
6//! embedder — or an in-process fidelity test — can't exercise the same wiring the
7//! `boatramp serve` binary runs (see `PLAN-node-library`).
8//!
9//! This crate is the extraction target. It starts with the parsed **config model**
10//! ([`config`]) and grows, incrementally and behaviour-preservingly, to host the
11//! `assemble(config) -> RunningNode` path. The binary re-exports [`config`] under
12//! its own `crate::config`, so moving the module here changes no call site.
13//!
14//! It depends on the concrete backend crates (Docker, storage, …) that
15//! `boatramp-server` deliberately does not, keeping `boatramp-server` a
16//! backend-agnostic library while this crate is the batteries-included assembler.
17
18pub mod auth;
19pub mod backends;
20pub mod blobs;
21pub mod compute;
22pub mod config;
23pub mod error;
24pub use error::Error;
25pub mod handlers;
26// The managed-SQL module carries the Postgres/MySQL operator-SQL + credential machinery (sqlx) AND
27// the migration substrate. It compiles whenever a sqlx engine OR `migrate` (⇒ the embedded libsql
28// migration runner) is on, so the libsql migrate parity is reachable on a node with no external sqlx
29// engine. The sqlx-specific items inside the module stay gated on the sqlx features.
30#[cfg(any(feature = "sql-postgres", feature = "sql-mysql", feature = "migrate"))]
31pub mod managed_sql;
32pub mod node;
33#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
34pub mod repair;
35#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
36pub mod tenant_sql;
37#[cfg(any(feature = "sql-postgres", feature = "sql-mysql"))]
38pub mod tenant_tombstone;
39pub use node::{assemble, NodeInput, RunningNode};