Architecture

Worklog is built with a layered local architecture designed for performance, predictability, and data integrity.

The Technical Stack

The application leverages modern web and systems technologies to provide a native-feeling desktop experience:

  • Shell: Tauri v2 (Rust) handles the window management, system tray, and secure filesystem access.
  • Frontend: SvelteKit provides a reactive, component-based UI with fast transitions.
  • Runtime: Bun manages dependencies and powers the development server.
  • Database: SQLite serves as the local source of truth, managed via the Tauri SQL plugin.

Data Flow

Worklog follows a strict unidirectional data flow to ensure the UI stays in sync with the underlying database.

UI Layer
Svelte Runes
Repositories
SQLite

1. UI Layer

Svelte components react to user interactions (clicks, keyboard shortcuts, drag-and-drop). They do not communicate with the database directly.

2. Hooks (The API)

Custom hooks (e.g., useWorkspace, useBoards, useTickets) act as the application’s internal API. They manage in-memory state and orchestrate calls to the repository layer.

3. Repository Layer

Located in src/lib/db, repositories handle the translation between application types and SQL queries. They ensure data is properly serialized (e.g., labels stored as JSON strings) before being written to disk.

4. Persistence

Data is stored in a standard SQLite file inside your workspace directory: .worklog/worklog.db. This makes your project data portable and easy to back up.

Schema Migrations

To ensure your data is always compatible with the latest version of Worklog, the app includes a robust migration system. Every time the app starts, it checks the current schema version and applies any necessary SQL updates in order, ensuring no data loss during upgrades.

Data Transparency

Because we use standard SQLite, you can open your worklog.db file with any standard SQL viewer to inspect or export your data manually at any time.

Next: Development →