Skip to main content

Architecture

Understanding the mimOE architecture is essential for building efficient, reliable mims and AI agents. This section covers the fundamental concepts, request processing, and platform limitations.

What You'll Learn​

This section explains how mimOE works under the hood, from the Device-First Continuum philosophy to the technical details of request processing and platform constraints.

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

Platform Constraints​

Learn about the technical limitations and design considerations:

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

Key Concepts​

Serverless-on-Device​

mimOE implements serverless execution on edge devices. mims are instantiated on-demand per request and terminated after response, minimizing memory footprint.

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)

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:

AspectJavaScriptWebAssembly
RuntimemimOE JS (ES5)WASM (no WASI)
LanguageJavaScriptRust, C, C++
Best forMost applicationsPerformance-critical
SDKcontext objectImported functions
ToolingWebpack + BabelRust/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:

Foundation First

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