01 / 08 Case study
NativeCharts
One trading product across desktop, web, and mobile, built on shared Rust contracts for live state, transport recovery, and data-dense interface behavior.
3
Dioxus clients
1
Shared client runtime
14
Packages across the complete system
02 / 08 The product problem
Three clients should behave like one product without copying critical logic
NativeCharts separates a headless client runtime, shared application shell, and UI contracts from platform-specific startup. Live quotes, subscriptions, stale-data evaluation, reconnect, and checkpoint snapshots follow one model whether the interface runs on desktop, web, or mobile.
Product consistency
The same states and recovery behavior on every platform
Client core owns subscription state, hot quote state, stale-data evaluation, and restore-friendly checkpoints. Platform applications do not invent separate versions of that logic.
Information density
Charting and market state need priorities, not decorative panels
Shared UI contracts organize viewport, watchlist, selection, and live-state projections so dense information remains scannable under load.
Reliable degradation
The fast path cannot be the only path
WebSocket JSON provides a reliable compatibility transport while the browser-safe datagram boundary is limited to hot L1 updates. Control and recovery messages remain reliable.
03 / 08 Product stack
Shared Rust behavior beneath three Dioxus surfaces
NativeCharts uses trading-client-core for live state and recovery, trading-app-shell for the shared product contract, trading-ui-components for renderer-neutral presentation, and separate desktop, web, and mobile applications.
04 / 08 Product flow
Market data enters once; every platform receives the same product truth
The flow prevents a renderer from becoming domain authority. That keeps behavior consistent and makes platform adaptation smaller and testable.
- D
Live delivery
Aggregator edge frames arrive through reliable or restricted hot-L1 transport.
- C
Client core
Decodes, validates, and updates subscriptions, quotes, stale state, and checkpoints.
- S
App shell
Turns headless state into one product lifecycle and UI-facing snapshots.
- U
UI contracts
Shared components and states without allowing a platform to acquire domain logic.
- 3
Three clients
Desktop, web, and mobile compose one architecture around environment capabilities.
05 / 08 Decisions
The decisions that shape the system
Implemented
Headless runtime before renderer
Client state, decoding, and recovery live in a Rust library with no Dioxus components or provider-specific payloads.
Implemented
Reliability follows message type
Only an L1 update may use an unreliable datagram; snapshots, control, health, and replay directives reject that path.
Implemented
Disk stays outside the hot path
The runtime drains dirty checkpoint snapshots while the file adapter writes versioned JSON through atomic replacement.
Boundary
Platform transport remains an adapter
Core runtime proves wire contracts and ingest behavior; concrete browser and native network clients are not misrepresented as its responsibility.
06 / 08 Product evidence
What is implemented beneath the interface
- Three Dioxus application crates for desktop, web, and mobile over one shared application shell
- Versioned WebSocket JSON edge decoding with frame, protocol, reliability, and payload-label validation
- A replay runtime connecting core-hub, aggregator, and client core without product UI dependencies
- Subscription ownership, reconnect, and stale-data evaluation in the shared headless runtime
- An atomic local checkpoint adapter and shared key-value persistence contract for future platform stores
08 / 08 The next move
Does your complex product need to behave consistently across more than one platform?
I can help separate shared product logic from renderers, transport, and platform storage before the clients begin to diverge.
Discuss the product->Explore application development->