Backend Application State
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
The Backend Application State in Augenblick serves as the central management system for persistent data, file system organization, and runtime configuration within the Rust-based Tauri core. It encapsulates the database connection, directory paths for drafts and trash, and the synchronization logic between the frontend user interface and the underlying SQLite storage.
This system ensures that note metadata, user preferences (such as themes and expiry intervals), and UI states (such as sidebar width and the currently selected note) are preserved across application restarts. It acts as the "source of truth" for the application's data model, coordinating between the SQLite database and the local file system.
Core State Architecture
The backend state is encapsulated primarily in the AppState struct, which is initialized at application startup and managed as a shared state within the Tauri runtime.
AppState Components
The state consists of two primary parts: a thread-safe database connection and a set of verified filesystem paths.
- Database Connection: An
Arc<Mutex<Connection>>providing shared, synchronized access to theaugenblick.dbSQLite database. - AppPaths: A collection of
PathBufobjects pointing to critical application directories, includingdrafts,trash, and the root data directory.
Sources: src-tauri/src/app_state.rs:8-18, src-tauri/src/commands.rs:13-17
Initialization Flow
During initialization, the backend resolves the standard application data directory, creates the necessary folder structure, and opens the database connection. It also sets the AUGENBLICK_LOG_PATH environment variable for debugging.
The initialization process ensures all required directories exist before the application becomes interactive.
Sources: src-tauri/src/app_state.rs:21-49
Data Persistence Models
The application differentiates between persistent settings and volatile application UI state.
Settings vs. App State
| Category | Purpose | Examples |
|---|---|---|
| Settings | User-configurable preferences. | theme, expiry_minutes, trash_retention_days |
| App State | UI and session persistence. | sidebarWidth, selectedNoteId, viewMode |
Sources: src-tauri/src/commands.rs:136-189, plans/migration.inventory.md:14-25
Database Schema
The persistence layer utilizes SQLite with the following primary tables:
- notes: Stores metadata for every note, including unique IDs, titles, previews, and file paths.
- app_state: A key-value store for UI persistence.
- settings: A key-value store for application behavior configuration.
Sources: plans/migration.inventory.md:14-36, src-tauri/src/commands.rs:163-189
State Synchronization Logic
State is synchronized between the frontend and backend through a series of IPC (Inter-Process Communication) commands.
UI State Persistence
The frontend (Zustand store) debounces updates to the backend to minimize disk I/O. For instance, sidebarWidth and viewMode are written to the app_state table approximately 250ms after the last change.
Note Lifecycle State
When a note is created or updated, the backend manages the transition between Draft and Saved storage states.
- Drafts: Metadata is stored in DB; content is stored in the
drafts/directory. - Saved: Metadata is stored in DB; content is stored at a user-defined path (utilizing security-scoped bookmarks on macOS).
Sources: src-tauri/src/notes/write.rs:13-43, plans/migration.inventory.md:73-108
API Endpoints (Tauri Commands)
The backend exposes several commands to manipulate the application state:
| Command | Parameters | Description |
|---|---|---|
app_state_get_all | None | Retrieves all key-value pairs from the UI state table. |
app_state_set | key: String, value: String | Persists a UI state variable. |
settings_get_all | None | Returns the current user settings (theme, expiry, etc.). |
settings_set | key: String, value: String | Updates a specific application setting. |
note_set_active | id: String | Updates the last_interaction timestamp for a note. |
Sources: src-tauri/src/commands.rs:136-189, src-tauri/src/notes/write.rs:77-85
Web Compatibility Shim
For environments where a native Rust backend is unavailable (e.g., web-based testing or development), a shim replicates the backend state logic using localStorage.
The shim maintains parity with the Rust backend by implementing the same command patterns and data structures, such as deriveTitlePreview and the WebDb type.
Sources: src/lib/tauri/shim.ts:1-20, src/lib/tauri/shim.ts:311-326
Conclusion
The Backend Application State is a robust system designed to balance performance with data integrity. By utilizing a combination of SQLite for structured metadata and a specific file hierarchy for note content, it provides a reliable foundation for Augenblick's auto-expiry and note management features. The architecture's reliance on shared state via Tauri's State manager ensures that data remains consistent across the various threads and commands that drive the application.