Building for Production
Relevant source files
The following files were used as context for generating this wiki page:
Production builds for Mailiner transform the Rust source code into a size-optimized WebAssembly (WASM) bundle suitable for browser deployment. The build process targets the wasm32-unknown-unknown architecture and employs specific optimization levels and security policies to ensure efficiency and privacy.
Sources: README.md:10-12, AGENTS.md:6-7
Build Process and Optimization
The production build uses the Dioxus CLI to orchestrate the compilation and optimization of the mailiner-app crate. Unlike development builds which can reach 100 MB, the production output is significantly reduced in size.
Build Commands
To generate a production-ready bundle, execute the following command from the workspace root:
dx build -p mailiner-app --release --web --debug-symbols=false
Sources: README.md:94-96, crates/mailiner-app/README.md:20-22
Optimization Strategies
The build pipeline utilizes the workspace wasm-release profile and wasm-opt to minimize binary size.
| Tool/Setting | Configuration | Purpose |
|---|---|---|
| Profile | wasm-release | Enables Link Time Optimization (LTO) |
| Opt-level | s | Optimizes for binary size |
| Debug Info | debug = false | Prevents wasm-opt from aborting due to DWARF issues |
| Wasm-opt | Enabled | Runs post-processing to strip metadata and shrink the WASM file |
Sources: README.md:100-104, crates/mailiner-app/Dioxus.toml:29-33
Build Pipeline Flow
The following diagram illustrates the transformation from source code to the final production artifacts.
The diagram shows the sequence of compilation and optimization steps that produce the final web-ready artifacts.
Sources: README.md:98-104, crates/mailiner-app/Dioxus.toml:31-33
Runtime Constraints and Target Environment
Mailiner targets the browser environment via the Dioxus crate. This specific target imposes technical constraints on dependency selection and resource management.
- WASM Compatibility: Not all Rust crates support the WASM target. Developers must choose alternative crates or implement minimal functionality directly within Mailiner.
- Performance Metrics: Performance and memory efficiency are critical. The application implements lazy loading, streaming, and LRU caching to manage memory within browser limits.
- Networking: Browsers cannot create direct TCP connections. Production deployments rely on a
ws-tcp-proxyto route WebSocket traffic to IMAP/SMTP servers.
Sources: AGENTS.md:6-14, README.md:14-20
Security Configuration
The production application employs a Content-Security-Policy (CSP) to harden the environment against XSS and unauthorized data access.
Baseline Policy
A baseline CSP is injected via a document <meta> tag after the WASM App mounts. For optimal security, an equivalent policy should be sent as an HTTP response header at deploy time.
| Directive | Policy | Requirement |
|---|---|---|
script-src | 'self' 'wasm-unsafe-eval' | Required to instantiate WASM |
style-src | 'self' 'unsafe-inline' | Required for Dioxus virtual list and layout |
connect-src | 'self' ws: wss: http: https: | Necessary for user-configured proxies |
img-src | 'self' data: blob: http: https: | Supports cid rehydration and remote images |
Sources: README.md:38-75
CSP Deployment Flow
This diagram outlines how security policies are applied during the initial load and runtime of the application.
Sources: README.md:38-42, crates/mailiner-app/Dioxus.toml:19-21
Summary
Building Mailiner for production focuses on converting the Rust codebase into a highly optimized WASM package. By using dx build with specific release flags, the system strips debug info and applies size-oriented optimizations. Security is managed through a multi-layered CSP approach, while the architectural limitations of the browser are handled through cross-compilation techniques and external proxy servers.
Sources: README.md:10-12, README.md:98-104, AGENTS.md:6-14