44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# Sprimo Frontend Architecture
|
|
|
|
## Workspace Layout
|
|
|
|
- `crates/sprimo-app`: process entrypoint and runtime wiring.
|
|
- `crates/sprimo-api`: axum-based localhost control server.
|
|
- `crates/sprimo-config`: config schema, path resolution, persistence.
|
|
- `crates/sprimo-platform`: platform abstraction for overlay operations.
|
|
- `crates/sprimo-protocol`: shared API/state/command protocol types.
|
|
- `crates/sprimo-sprite`: sprite pack manifest loading and fallback logic.
|
|
|
|
## Runtime Data Flow
|
|
|
|
1. `sprimo-app` loads or creates `config.toml`.
|
|
2. App builds initial `FrontendStateSnapshot`.
|
|
3. App starts `sprimo-api` on a Tokio runtime.
|
|
4. API authenticates commands and deduplicates IDs.
|
|
5. Commands are bridged from Tokio channel to Bevy main-thread systems.
|
|
6. Bevy systems apply commands to sprite state, window/platform operations, and config persistence.
|
|
7. Shared snapshot is exposed by API via `/v1/state` and `/v1/health`.
|
|
|
|
## Sprite Reload Semantics
|
|
|
|
- `SetSpritePack` uses a two-phase flow:
|
|
1. Validate and build candidate pack runtime (manifest + clips + atlas layout + texture handle).
|
|
2. Commit atomically only on success.
|
|
- On reload failure, current pack remains active and snapshot `last_error` is updated.
|
|
|
|
## Threading Model
|
|
|
|
- Main task: startup + shutdown signal.
|
|
- API task: axum server.
|
|
- Bridge task: forwards API commands into Bevy ingest channel.
|
|
- Bevy main thread: rendering, animation, command application, and window behavior.
|
|
- Optional hotkey thread (Windows): registers global hotkey and pushes recovery events.
|
|
- Snapshot is shared via `Arc<RwLock<_>>`.
|
|
|
|
## Design Constraints
|
|
|
|
- Bind API to localhost only.
|
|
- Token auth by default for mutating and state endpoints.
|
|
- Keep protocol crate renderer-agnostic for future backend/frontend reuse.
|
|
- Keep platform crate isolated for per-OS implementations.
|