Architecture

Understanding the mimOE architecture is essential for building efficient, reliable mims. This section covers the fundamental concepts, request processing, and design trade-offs.

Start with the Architecture Overview, then explore How Requests Flow Through mimOE and Design Trade-offs.

Architecture Topics

Architecture Overview

Learn about mimOE's serverless-on-device architecture and the Device-First Continuum (DFC) philosophy:

• What is mimOE and how it differs from cloud-first architectures
• Device-First Continuum explained with diagrams
• Runtime components and execution engines
• Cross-platform architecture
• Memory and resource model
• Security model

Request Lifecycle

Understand how requests flow through mimOE from receipt to response:

• Five stages of request processing
• Authentication and routing
• mim instantiation and context injection
• Request processing and async operations
• Response generation and serialization
• Instance termination and cleanup
• Performance optimization strategies

Design Trade-offs

Understand the runtime design decisions that enable cross-platform portability:

• JavaScript runtime (ES5-based, not Node.js)
• Stateless execution model
• WASM runtime (no WASI)
• Resource considerations (memory, timeout, storage)
• Networking model
• Cross-platform considerations
• Workarounds and best practices

Key Concepts

Serverless-on-Device

mimOE runs mims as serverless functions on edge devices. Each mim instance is created when a request arrives and destroyed after the response is sent, so memory is immediately freed.

Key implication: No state persists between requests. Use context.storage for persistence.

Device-First Continuum

Processing starts on the device where data originates. Cloud services are available when needed, but not required.

Benefits:

• Reduced latency (no round-trip to cloud)
• Enhanced privacy (data stays local)
• Offline capability (works without internet)
• Cost efficiency (reduced cloud costs)
• Improved device utilization (devices contribute compute, not just consume)

Request-Driven Execution

All mims are triggered by HTTP requests. There are no long-running processes or background tasks.

What this means:

• mims are REST API endpoints
• Execution is synchronous (request → response)
• For async patterns, use storage and external triggers

Development Paths

mimOE supports two development approaches:

Aspect	JavaScript	WebAssembly
Runtime	mimOE JS (ES5)	WASM (no WASI)
Language	JavaScript	Rust, C, C++
Best for	Most applications	Performance-critical
SDK	context object	Imported functions
Tooling	Webpack + Babel	Rust, C, C++ compiler

Architecture Principles

1. Stateless by Design

Every request starts with a fresh instance. This ensures:

• Isolation between requests
• Predictable behavior
• Easy horizontal scaling

2. Minimal Footprint

The runtime is optimized for resource-constrained devices:

• Core runtime: ~5-10 MB
• JavaScript engine: ~200 KB
• Per-request overhead: ~100-500 KB

3. Security Through Isolation

mims run in sandboxed environments:

• Limited filesystem access
• No process spawning
• Limited network access (HTTP/HTTPS only)
• Memory safety enforced

4. Cross-Platform Portability

Write once, run anywhere:

• Desktop: macOS, Linux, Windows
• Mobile: iOS, Android
• Embedded / RTOS: QNX (Enterprise Package)
• Single codebase, multiple platforms

Next Steps

Choose your learning path:

• Architecture Overview: Start with fundamental concepts
• Request Lifecycle: Understand request processing
• Design Trade-offs: Understand the runtime design decisions
• Getting Started: Set up your environment
• JavaScript Development: Build with JavaScript

Foundation First

We recommend reading the Architecture Overview first to understand the fundamental concepts before diving into development.