Architecture

Yasumu is built on a hybrid architecture that combines web technologies with native performance. This page explains how Yasumu is structured.

Overview

Yasumu consists of three main layers:

┌─────────────────────────────────────────────────────┐
│                   Frontend (Next.js)                │
│              React UI, State Management             │
├─────────────────────────────────────────────────────┤
│                  Tauri Shell (Rust)                 │
│        Window Management, IPC, Native Bridge        │
├─────────────────────────────────────────────────────┤
│            Custom JavaScript Runtime                │
│     Deno-based runtime with Drizzle + Hono          │
│       HTTP Requests, Database, Business Logic       │
└─────────────────────────────────────────────────────┘

Frontend Layer

The frontend is built with Next.js and React, providing:

• Modern React UI — Component-based architecture with hooks
• Static Export — Compiled to static HTML/JS for Tauri
• State Management — React context and local state
• UI Components — Custom component library

Key Technologies

Static Export

Yasumu uses Next.js static export (output: 'export') to generate static HTML, CSS, and JavaScript files that are bundled with the Tauri application:

const nextConfig = {
  output: 'export',
};

Tauri Shell

The Tauri layer (written in Rust) serves as the desktop shell:

• Window Management — Native window creation and management
• IPC Bridge — Communication between frontend and runtime
• Native APIs — File system access, system dialogs, etc.
• Cross-Platform — Single codebase for Windows, macOS, Linux
• Security — Sandboxed execution with explicit permissions

Capabilities System

Tauri uses a capabilities system to control what the application can access:

{
  "identifier": "main-capability",
  "windows": ["main"],
  "permissions": ["core:default", "http:default", "fs:default"]
}

Custom JavaScript Runtime (Tanxium)

The actual backend logic runs in a custom JavaScript runtime called Tanxium, which is built on Deno:

Core Components

Why a Custom Runtime?

• TypeScript Native — First-class TypeScript support without compilation
• Web-Standard APIs — Uses familiar APIs like fetch
• Secure by Default — Explicit permission model
• Embedded — Runs within the Tauri application

Runtime Responsibilities

The JavaScript runtime handles:

1. HTTP Requests — Making API calls to external services
2. Database Operations — Storing and retrieving workspace data
3. Echo Server — Built-in server for testing requests
4. SMTP Server — Catch-all email server for testing
5. Business Logic — Request processing, variable resolution, etc.

Data Flow

Request Lifecycle

1. User Action — User clicks "Send" in the UI
2. Frontend Processing — Variables are collected, request prepared
3. IPC to Runtime — Request sent to JavaScript runtime via Tauri
4. HTTP Request — Runtime makes the actual HTTP call
5. Response Received — Response data captured
6. Persistence — Data stored via Drizzle
7. UI Update — Response displayed in the frontend

File System Operations

┌─────────────────┐
│    Frontend     │
│  (read/write)   │
└────────┬────────┘
         │ IPC
         ▼
┌─────────────────┐
│  JavaScript     │
│    Runtime      │
└────────┬────────┘
         │
         ▼
┌─────────────────┐
│   File System   │
│   (workspace)   │
└─────────────────┘

The .ysl Format

Yasumu Schema Language (YSL) is a custom format for storing API definitions:

Design Goals

• Human Readable — Easy to read and understand
• Diff Friendly — Clean diffs for version control
• Extensible — Room for future additions
• Structured — Consistent block-based format

File Naming

YSL files are named using unique IDs (not human-readable names):

yasumu/
├── workspace.ysl
├── environment/
│   ├── h49ehcz1o96rglpym0qjqr3a.ysl
│   └── z85bde4ytdta7d1u0ndjfoh6.ysl
├── rest/
│   ├── wmz1pu98ovohr1k44dbldpjt.ysl
│   └── uaro9t8o2j31rufvghiyn4yr.ysl
├── smtp.ysl
└── yasumu-lock.json

The human-readable names are stored inside the files in the metadata block.

Package Structure

Yasumu is organized as a monorepo:

yasumu/
├── apps/
│   ├── yasumu/        # Main Tauri application
│   ├── www/           # Marketing website
│   └── docs/          # Documentation (Fumadocs)
└── packages/
    ├── common/        # Shared types
    ├── core/          # Core logic
    ├── den/           # Dependency injection
    ├── rpc/           # RPC utilities
    ├── schema/        # YSL parser/serializer
    ├── tanxium/       # Custom JavaScript runtime
    └── ui/            # Shared UI components

Performance Considerations

Native HTTP

HTTP requests are made through the JavaScript runtime using modern fetch APIs, providing:

• Connection management
• HTTP/2 support where available
• Efficient TLS handling

Memory Efficiency

• Static frontend (no server runtime)
• Efficient Rust shell via Tauri
• On-demand JavaScript execution
• Lazy loading of workspace data

Security Model

Tauri Sandboxing

• Explicit capability grants
• Controlled file system access
• Secure IPC communication

Runtime Permissions

The JavaScript runtime operates with controlled permissions:

• Network access for HTTP requests
• File system access for workspace operations
• Database access for persistence

Extensibility

Planned Plugin System

Future releases will include a plugin API for:

• Custom protocols
• Authentication providers
• Response formatters
• Import/export formats