Workspace Structure

Relevant source files

• Cargo.lock
• Cargo.toml
• assets/Muxio-logo.svg
• extensions/README.md

This document describes the organization of the rust-muxio workspace, including all crates, their locations, purposes, and how they relate to each other. For information about the conceptual architecture and design patterns, see Layered Architecture.

Purpose and Organization Pattern

The rust-muxio project is organized as a Cargo workspace following a "core + extensions" pattern. The workspace contains a single core library (muxio) that provides transport-agnostic stream multiplexing, plus seven extension crates that build RPC functionality on top of the core, plus two example crates demonstrating usage.

This modular structure allows consumers to depend on only the functionality they need. For instance, a WASM client application can include only muxio, muxio-rpc-service, muxio-rpc-service-caller, and muxio-wasm-rpc-client without pulling in Tokio server dependencies.

Sources: Cargo.toml:19-31 extensions/README.md:1-4

Workspace Directory Structure

Sources: Cargo.toml:19-31 extensions/README.md:1-4

Workspace Member Crates

Core Library

The muxio crate is the foundation of the entire system. It provides runtime-agnostic, transport-agnostic multiplexing capabilities with no assumptions about RPC, serialization, or network protocols. All other crates in the workspace depend on this core.

Sources: Cargo.toml:9-17 Cargo.toml41

RPC Extension Crates

These seven extension crates build the RPC framework on top of the core multiplexing library. The first three (muxio-rpc-service, muxio-rpc-service-caller, muxio-rpc-service-endpoint) define the RPC abstraction layer, while the next three provide concrete transport implementations for different platforms. The muxio-ext-test crate contains shared testing infrastructure.

Sources: Cargo.toml:22-28 Cargo.toml:43-47

Example Crates

The example crates demonstrate real-world usage patterns. example-muxio-rpc-service-definition shows how to define shared service contracts that work across all platforms, while example-muxio-ws-rpc-app provides a working end-to-end application.

Sources: Cargo.toml:29-30 Cargo.toml42

Crate Dependency Relationships

Sources: Cargo.lock:426-954

Workspace Configuration

The workspace is configured through the root Cargo.toml file, which defines shared package metadata and dependency versions.

Shared Package Metadata

All workspace members inherit these common properties:

Sources: Cargo.toml:1-7

Workspace Dependencies

The workspace defines shared dependency versions in the [workspace.dependencies] section to ensure consistency across all crates:

Intra-workspace Dependencies:

• Path-based references to all workspace members
• Version locked to "0.10.0-alpha"

Key External Dependencies:

• async-trait = "0.1.88" - Async trait support
• axum = { version = "0.8.4", features = ["ws"] } - Web framework with WebSocket support
• bitcode = "0.6.6" - Binary serialization
• tokio = { version = "1.45.1" } - Async runtime
• tokio-tungstenite = "0.26.2" - WebSocket implementation
• tracing = "0.1.41" - Structured logging
• xxhash-rust = { version = "0.8.15", features = ["xxh3", "const_xxh3"] } - Fast hashing for method IDs

Sources: Cargo.toml:39-64

Platform-Specific Compilation Targets

The workspace supports both native and WASM compilation targets. The core library (muxio), RPC abstraction layer (muxio-rpc-service, muxio-rpc-service-caller, muxio-rpc-service-endpoint), and service definitions are fully platform-agnostic. Transport implementations are platform-specific: Tokio-based crates compile for native targets, while muxio-wasm-rpc-client compiles to WebAssembly.

Sources: Cargo.lock:830-954

Resolver Configuration

The workspace uses Cargo's v2 resolver:

This ensures consistent dependency resolution across all workspace members and enables Cargo's newer resolver features including better handling of target-specific dependencies.

Sources: Cargo.toml32

Development Dependencies

The core muxio crate defines development dependencies that are only used for testing:

• bitcode (workspace version) - Used for serialization in tests
• rand = "0.9.1" - Random number generation for test data
• tokio (workspace version, features = ["full"]) - Full Tokio runtime for async tests

These dependencies are separate from the minimal runtime dependencies of the core library, maintaining its lightweight footprint in production builds.

Sources: Cargo.toml:67-70

Dismiss

Refresh this wiki

Enter email to refresh