2.2 KiB

Raw Permalink Blame History

ADR-001: Rust Workspace Structure

Status

Accepted

Context

We need to port the WiFi-DensePose Python application to Rust for improved performance, memory safety, and cross-platform deployment including WASM. The architecture must be modular, maintainable, and support multiple deployment targets.

Decision

We will use a Cargo workspace with 9 modular crates:

wifi-densepose-rs/
├── Cargo.toml                    # Workspace root
├── crates/
│   ├── wifi-densepose-core/      # Core types, traits, errors
│   ├── wifi-densepose-signal/    # Signal processing (CSI, phase, FFT)
│   ├── wifi-densepose-nn/        # Neural networks (DensePose, translation)
│   ├── wifi-densepose-api/       # REST/WebSocket API (Axum)
│   ├── wifi-densepose-db/        # Database layer (SQLx)
│   ├── wifi-densepose-config/    # Configuration management
│   ├── wifi-densepose-hardware/  # Hardware abstraction
│   ├── wifi-densepose-wasm/      # WASM bindings
│   └── wifi-densepose-cli/       # CLI application

Crate Responsibilities

wifi-densepose-core: Foundation types, traits, and error handling shared across all crates
wifi-densepose-signal: CSI data processing, phase sanitization, FFT, feature extraction
wifi-densepose-nn: Neural network inference using ONNX Runtime, Candle, or tch-rs
wifi-densepose-api: HTTP/WebSocket server using Axum
wifi-densepose-db: Database operations with SQLx
wifi-densepose-config: Configuration loading and validation
wifi-densepose-hardware: Router and hardware interfaces
wifi-densepose-wasm: WebAssembly bindings for browser deployment
wifi-densepose-cli: Command-line interface

Consequences

Positive

Clear separation of concerns
Independent crate versioning
Parallel compilation
Selective feature inclusion
Easier testing and maintenance
WASM target isolation

Negative

More complex dependency management
Initial setup overhead
Cross-crate refactoring complexity

2.2 KiB Raw Permalink Blame History