AutoCalc_v1

Current technology landscape and viability

Rust/WASM technology maturity has reached production readiness in 2025, with multiple database solutions and established architectural patterns. The ecosystem offers SQLite WASM with Origin-Private File System support, Limbo (a Rust-native SQLite reimplementation), and DuckDB-WASM for analytical workloads. Performance overhead typically runs 1.75x-2.5x slower than native code, but this cost is offset by unified codebases, local-first architecture, and offline capabilities.

The formulation software industry has simultaneously evolved toward cloud-native, microservices-based architectures with advanced optimization engines. Leading solutions like AFOS and Format Solutions' Brill® have successfully migrated to web-based platforms, demonstrating proven patterns for complex domain migration.

Architecture patterns for formulation software migration

Recommended hybrid architecture

The optimal architecture combines client-side Rust/WASM processing with strategic data distribution:

Database layer strategy:

Primary transactional data: Limbo/SQLite-WASM for formulations and user data
Analytical operations: DuckDB-WASM for ingredient analysis and cost optimization
Caching layer: IndexedDB for frequently accessed ingredient databases
File storage: Origin-Private File System for product images and regulatory documents

Application architecture:

┌─────────────────┐    ┌──────────────────┐
│   Rust/WASM     │    │   JavaScript UI  │
│   - Database    │◄──►│   - React/Vue    │
│   - Calculations│    │   - Visualization│
│   - Validation  │    │   - User Input   │
└─────────────────┘    └──────────────────┘
         │                       │
         ▼                       ▼
┌─────────────────────────────────────────┐
│        Browser Storage Layer            │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │IndexedDB│ │  OPFS   │ │LocalStg │   │
│  │Metadata │ │ Files   │ │ Config  │   │
│  └─────────┘ └─────────┘ └─────────┘   │
└─────────────────────────────────────────┘

Multi-tenancy and data sovereignty

Shared database, shared schema emerges as the optimal multi-tenancy pattern for formulation software. This approach provides cost efficiency, simplified maintenance for regulatory updates, and resource optimization while supporting row-level security with automatic tenant isolation.

Client-side data sovereignty implementation leverages local-first architecture patterns with selective sync capabilities. Users maintain complete control over proprietary formulations while enabling collaboration through controlled data sharing mechanisms.

Migration strategy from legacy VB.Net systems

Strangler fig pattern implementation

Microsoft's recommended Strangler Fig pattern provides the lowest-risk approach for complex domain migration:

Phase 1: Façade establishment

Deploy reverse proxy routing traffic between legacy VB.Net and new components
Implement monitoring and logging for both systems
Establish data synchronization mechanisms

Phase 2: Incremental component migration

Start with isolated services (authentication, document management)
Implement microservices architecture for new components
Maintain separate databases with synchronization during transition

Phase 3: Business logic migration

Extract mathematical formulation algorithms into Rust/WASM services
Migrate calculation engines with comprehensive validation frameworks
Implement comprehensive testing for critical calculations

Phase 4: Complete transition

Migrate core data operations and database interactions
Decommission legacy VB.Net components systematically
Complete user migration with feedback incorporation

Domain complexity management

Scientific calculation precision requires special attention during migration. The research identifies proven patterns for logic extraction into separate services, validation frameworks for critical calculations, and data integrity maintenance throughout the migration process.

Regulatory compliance mapping must document requirements throughout migration, ensuring audit trail preservation and compliance continuity across system transitions.

Database design for unified schemas

Core formulation data model

Modern formulation systems implement hierarchical product structures supporting sub-assemblies, ingredient groups, and packaging specifications similar to PLM/ERP Bill-of-Materials structures. The unified schema design includes:

Primary entities:

Ingredients: Raw materials with nutritional profiles, sourcing specifications, regulatory classifications
Nutrients: Individual components with measurement units and bioavailability factors
Coefficients: Mathematical relationships including digestibility factors and interaction coefficients
Formulas: Multi-level hierarchical structures supporting base formulations and variants
Models/Versions: Framework managing multiple scenarios and historical versions

Implementation pattern:

CREATE TABLE formulas (
    id INT PRIMARY KEY,
    tenant_id INT NOT NULL,
    name VARCHAR(255),
    version VARCHAR(50),
    created_date TIMESTAMP,
    INDEX(tenant_id)
);

CREATE TABLE ingredients (
    id INT PRIMARY KEY,
    tenant_id INT NOT NULL,
    name VARCHAR(255),
    nutrient_profile JSONB,
    INDEX(tenant_id)
);

Schema evolution strategies

Zero-downtime migration patterns using dual writing strategies enable continuous operation during schema updates. The four-phase approach (add elements, implement dual writing, switch reads, remove deprecated elements) ensures backward compatibility while supporting distributed client synchronization.

Technology stack and tooling recommendations

Development toolchain

Primary development tools:

wasm-pack: Production-ready build pipeline with JavaScript interop
trunk: Web application bundler with hot reload development server
SQLite WASM/Limbo: Client-side database solutions with persistence
DuckDB-WASM: Analytics engine for complex formulation queries

Project structure optimization:

formulation-app/
├── Cargo.toml           # Rust configuration
├── src/
│   ├── lib.rs           # WASM entry point
│   ├── database/        # Database operations
│   ├── calculations/    # Formulation algorithms
│   └── models/          # Domain models
├── www/                 # Frontend assets
├── tests/               # Browser-based testing
└── pkg/                 # Generated WASM output

Performance optimization strategies

Build optimization configuration:

[profile.release]
lto = true              # Link Time Optimization
opt-level = "s"         # Optimize for size
panic = 'abort'         # Smaller panic handling

[profile.wasm-release]
inherits = "release"
opt-level = "z"         # Aggressive size optimization

Runtime performance patterns:

Lazy loading for ingredient databases with progressive enhancement
Computation distribution between WASM (calculations) and JavaScript (UI)
Intelligent caching with hot data in memory, warm data in IndexedDB

MVP development roadmap

Phase 1: Foundation (Weeks 1-4)

Technical infrastructure:

Set up Rust/WASM build pipeline with wasm-pack and trunk
Choose database solution (recommend starting with Limbo for simplicity)
Implement basic CRUD operations for formulations
Establish offline-first storage architecture

Legacy system integration:

Comprehensive VB.Net system assessment and documentation
Architecture design and technology selection validation
Development environment setup with CI/CD pipeline
Initial proof of concept with simple formulation calculations

Phase 2: Core migration (Weeks 5-12)

Data layer modernization:

Implement unified database schema with multi-tenancy support
Migrate core ingredient databases with search and filtering
Build formulation calculation engines in Rust/WASM
Establish data synchronization between legacy and new systems

User interface development:

Create modern web interface with real-time validation
Implement collaborative features with conflict resolution
Build regulatory compliance calculations and reporting
Test performance optimization strategies

Phase 3: Advanced features (Weeks 13-20)

Business logic completion:

Complete migration of complex optimization algorithms
Implement comprehensive audit trails and version control
Add advanced analytics and reporting capabilities
Build data export/import capabilities for migration

Production preparation:

Comprehensive testing across representative datasets
Performance benchmarking against legacy system
Security audit and penetration testing
User training and change management planning

Phase 4: Production deployment (Weeks 21-24)

System transition:

Gradual traffic shifting using Strangler Fig pattern
Complete user migration with feedback incorporation
Legacy system decommissioning procedures
Post-deployment monitoring and optimization

Business continuity:

Zero-downtime migration validation
Rollback procedures and contingency planning
Complete documentation and knowledge transfer
Long-term maintenance and support planning

Risk mitigation and success factors

Technical risk management

Performance considerations: While WASM typically runs 1.75x-2.5x slower than native code, the research demonstrates this overhead is acceptable for most formulation software use cases, particularly when balanced against architectural benefits.

Data integrity protection: Shadow writing during transition phases, parallel system operation with data validation, and comprehensive backup procedures ensure zero data loss during migration.

Browser compatibility: Progressive enhancement patterns with fallbacks for older browsers ensure broad accessibility while leveraging modern capabilities where available.

Business risk mitigation

User adoption strategy: Gradual interface transitions with comprehensive training, feedback collection systems, and rapid iteration based on user input minimize disruption and maximize acceptance.

Regulatory compliance continuity: Complete mapping of regulatory requirements, audit trail preservation, and compliance validation throughout migration ensure uninterrupted regulatory compliance.

Development expertise: The learning curve for Rust/WASM requires careful team planning, but the mature tooling ecosystem and extensive documentation support practical implementation timelines.

Implementation success criteria

Technical metrics:

Query performance: Sub-millisecond response times for local database operations
Bundle size: Optimized WASM binaries under 2MB for acceptable load times
Offline capability: Full functionality without network connectivity
Data synchronization: Reliable conflict resolution and multi-user collaboration

Business outcomes:

Migration timeline: 24-week completion with minimal business disruption
User satisfaction: Improved workflow efficiency and collaborative capabilities
Regulatory compliance: Maintained or improved compliance tracking and reporting
Total cost of ownership: Reduced infrastructure costs through client-side processing

The combination of mature Rust/WASM technology, proven migration patterns, and industry-validated database designs provides a clear path for modernizing legacy formulation software while achieving data sovereignty goals. Success depends on careful architectural planning, realistic performance expectations, and phased implementation that validates assumptions early and iterates based on real-world usage patterns.

PreviousLegacy Formulation Software Modernization: Rust/WASM Implementation Guide NextQ: Build a Azure AD DSL Language that can parse and manage Azure resources permissions, for example

Last updated 1 month ago