dwara_core/
lib.rs

1//! Gateway core: the shared config model, routing types, swappable trait
2//! definitions, listener/TLS machinery, and dataplane assembly consumed by
3//! the bin/admin/cli crates.
4//!
5//! # Organization
6//!
7//! This crate is organized as a set of domain directories (bounded
8//! contexts) behind this facade:
9//!
10//! - [`config`] — configuration schema and the `parse_gateway` entry point
11//! - [`extensions`] — the OSS/Ent edition boundary as a type boundary
12//! - [`snapshot`] — the config compile pipeline (validate -> compile -> publish)
13//! - [`observability`] — tracing, metrics, and access logging
14//! - [`events`] — the in-process event bus and webhook delivery (DW-044)
15//! - [`state`] — SQLite-backed durable state and schema migrations
16//! - [`security`] — TLS, authentication, authorization
17//! - [`resilience`] — passive health, retries, circuit breaker,
18//!   adaptive + origin-driven rate-limit tuning (DW-089)
19//! - [`dataplane`] — the reverse-proxy request path, its upstreams, and
20//!   active health probing
21//! - [`supervision`] — bounded panic-respawn supervision for accept
22//!   loops, shared by the bin and admin accept surfaces
23//! - [`error`] — the facade-level aggregate [`error::Error`] over the
24//!   domain error types, for boundary propagation
25//!
26//! # Dependency direction
27//!
28//! Dependencies point downward only; a domain may never be depended on by
29//! a domain above it:
30//!
31//! | Domain | May depend on |
32//! |---|---|
33//! | `config` | (nothing) |
34//! | `extensions` | `config` |
35//! | `observability` | (nothing) |
36//! | `events` | `config`, `observability` |
37//! | `snapshot` | `config`, `events` |
38//! | `state` | `config` |
39//! | `analytics` | `config`, `observability`, `extensions` |
40//! | `security` | `config`, `state`, `observability` |
41//! | `resilience` | `config`, `snapshot`, `extensions`, `observability`, `events` |
42//! | `plugins` | `config` (native filter trait + unified dispatch chain;
43//!   the `wasm` domain bridges its instances in via a generic adapter,
44//!   so `plugins` never imports `wasm` — see DW-119) |
45//! | `ai` | `config` (provider-adapter pack, DW-075: the canonical chat
46//!   vocabulary, the pure-translation [`ai::adapter::ProviderAdapter`]
47//!   seam, and the compiled alias table; the transport lives in
48//!   `dataplane`, which calls into it) |
49//! | `lifecycle` | `config`, `observability`, `analytics` (DW-110: API
50//!   lifecycle management -- developer portal, environment profiles,
51//!   API journey recorder; feature-gated behind `api_lifecycle`) |
52//! | `mesh` | `config`, `observability` (DW-107: service mesh mode --
53//!   sidecar traffic interception + SPIFFE/SPIRE mTLS identity; the
54//!   mTLS TLS integration point is a documented seam into `security`,
55//!   kept as a hand-off so the dependency direction stays downward;
56//!   feature-gated behind `mesh`, Ent-only) |
57//! | `dataplane` | all of the above |
58//! | `supervision` | (nothing — pure task plumbing, no domain imports) |
59//!
60//! (`dwara-bin`, `dwara-admin`, and `dwara-cli` depend on this crate.)
61//!
62//! # Path compatibility
63//!
64//! The modules were originally flat at the crate root. To keep every
65//! pre-restructure path (e.g. `dwara_core::proxy::handle`,
66//! `dwara_core::config::parse_gateway`, `dwara_core::tls`) compiling
67//! unchanged, the crate root re-exports each moved module as a path alias:
68//! `dwara_core::proxy` and `dwara_core::dataplane::proxy` (and likewise
69//! for `upstream`, `balance`, `hardening`, `health`, `active`, `retries`,
70//! `breaker`, `tls`, `authn`, `authz`, `store`, `migrations`) denote the
71//! same module. The aliases are `#[doc(hidden)]`: they still compile but
72//! stay out of the rendered docs. Use the domain-qualified path in new
73//! code (`dwara_core::dataplane::proxy`, `dwara_core::security::tls`).
74
75pub mod ai;
76pub mod analytics;
77// DW-058: CEL engine. Feature-gated behind the `cel` cargo feature
78// (default OFF) because cel-interpreter adds binary size.
79pub mod cel;
80pub mod config;
81pub mod dataplane;
82pub mod error;
83pub mod events;
84pub mod extensions;
85pub mod observability;
86// DW-119: native plugin filter trait + unified dispatch chain.
87// Feature-gated behind the `plugins` cargo feature (default OFF)
88// because it is the compile-in extension path (compiled-in Rust
89// filters); the proxy-wasm host (DW-055) is the portable ABI path.
90pub mod plugins;
91// DW-070: OpenAPI response validation. Feature-gated behind the
92// `openapi_validation` cargo feature (default OFF).
93pub mod openapi;
94pub mod resilience;
95pub mod security;
96pub mod snapshot;
97pub mod state;
98pub mod supervision;
99// DW-071: Synthetic monitoring. Built-in probes per route that
100// measure latency and uptime, feeding results into analytics and
101// webhooks.
102pub mod synthetic;
103// DW-061: API aggregation plugin pack. Feature-gated behind the
104// `aggregation` cargo feature (default OFF).
105pub mod aggregation;
106// DW-112: Agent-operable administration via MCP. Feature-gated
107// behind the `mcp` cargo feature (default OFF).
108pub mod mcp;
109// DW-067: Workspaces + RBAC + audit (Enterprise). Feature-gated
110// behind the `ent` cargo feature (default OFF).
111#[cfg(feature = "ent")]
112pub mod workspace;
113// DW-066: CP/DP split (Enterprise). Feature-gated behind the `ent`
114// cargo feature (default OFF).
115#[cfg(feature = "ent")]
116pub mod cp_dp;
117// DW-064: Kubernetes Gateway API translator. Feature-gated behind
118// the `k8s` cargo feature (default OFF).
119pub mod k8s_gateway;
120// DW-055: proxy-wasm host. Feature-gated behind the `wasm` cargo
121// feature (default OFF) because wasmtime + cranelift are significant
122// binary size against the DW-026 25MB budget.
123pub mod wasm;
124// DW-107: Service mesh mode (sidecar + SPIFFE/SPIRE mTLS identity).
125// Feature-gated behind the `mesh` cargo feature (default OFF). The
126// sidecar controller and SPIFFE Workload API client are SCAFFOLDED
127// (documented no-ops); the `spiffe` crate would be added when
128// production-ready. Ent-only.
129pub mod mesh;
130// DW-110: API lifecycle management (developer portal, environment
131// profiles, API journey recorder). Feature-gated behind the
132// `api_lifecycle` cargo feature (default OFF, flag-only). The config
133// schema (the top-level `lifecycle` block) is always present so configs
134// round-trip without the feature; when the feature is off the block is
135// accepted but inert (validation warns).
136pub mod lifecycle;
137
138// Path-compatibility aliases: these re-exports keep the historical
139// top-level module paths (`dwara_core::proxy`, `dwara_core::tls`, ...)
140// resolving after the move into domain directories. They are hidden
141// from docs so new code gravitates to the canonical domain paths. See
142// "Path compatibility" above.
143#[doc(hidden)]
144pub use dataplane::active;
145#[doc(hidden)]
146pub use dataplane::balance;
147#[doc(hidden)]
148pub use dataplane::hardening;
149#[doc(hidden)]
150pub use dataplane::proxy;
151#[doc(hidden)]
152pub use dataplane::upstream;
153#[doc(hidden)]
154pub use resilience::adaptive;
155#[doc(hidden)]
156pub use resilience::breaker;
157#[doc(hidden)]
158pub use resilience::health;
159#[doc(hidden)]
160pub use resilience::retries;
161#[doc(hidden)]
162pub use security::authn;
163#[doc(hidden)]
164pub use security::authz;
165#[doc(hidden)]
166pub use security::fips;
167#[doc(hidden)]
168pub use security::oidc;
169#[doc(hidden)]
170pub use security::pq;
171#[doc(hidden)]
172pub use security::tls;
173#[doc(hidden)]
174pub use state::migrations;
175#[doc(hidden)]
176pub use state::store;
dwara_core/lib.rs

dwara_core/
lib.rs
