← All Projects
Tauri Rust WebAssembly SQLite Desktop Development Software Architecture

2026-04-07

Creating a Tauri Application to Track My Lifestyle

2026-04-07

Since I moved out of my parents’ house during the COVID pandemic, I have wanted to build a single application that bundles together the tools I use to manage my life. That includes a budgeting app, a calendar, to-do lists, and anything else that becomes more useful when it can share data with the rest of the system. The core idea behind this project is a shared database: my calendar can inform my budget, and my budget can react to upcoming events.

Project Goals

Here were my goals for the project:

  • Focus on a single database that all applications can use
  • Create a simple UI that allows me to easily access all of my applications
  • Have a simple way to add new applications to the app in the future
  • Keep security in mind, especially since this app will be handling sensitive information like budgets and calendar events

Architecture

I chose Tauri because it lets me build a desktop application with web technologies that I already know, while still giving me access to Rust when I need it. More importantly, it fits the architecture I had in mind: packages can be written as Rust-based .wasm modules and then called from JavaScript. That gives me a clean way to swap out implementations or add new features over time.

SQLite was the obvious database choice. I wanted a relational database that did not require a separate server, and SQLite satisfies that requirement with very little overhead. The fact that it lives in a single file also makes the overall application much easier to manage.

The WebAssembly layer is where the application becomes more interesting. Basically, I wanted a base application that handles the UI shell, the database, security checks, and package management. Everything else lives in packages built on top of that base.

The base application exposes a simple API that packages can use to interact with the database and the rest of the system. That means I can add new features later without having to redesign the entire application. If I want to build a new module, I only need to implement the package itself and have it talk to the host through that API.

The UI itself is intentionally simple. I define a set of basic components in the base application, and each package returns a JSON object that tells the host how to render its interface. This lets a package define its own screens without needing to know about the underlying rendering details. The base application just interprets that JSON and renders the UI accordingly.

In terms of security, I tried to follow best practices for handling sensitive information. Module writes go through a gatekeeper that ignores guest-supplied identity, validates identifiers and column definitions, and uses parameterized SQLite writes. The frontend also sanitizes SVG before any HTML injection point.

That said, the system is not complete. I am still working on a trusted package installation flow that would let users verify the integrity of packages before installing them. Another weakness is that packages do not yet have resource limits, which means a malicious package could try to consume too much of the system. Both of those areas still need more work.

Current Status

What I have built so far, with help from AI, is a functional foundation for the larger application. I have a simple UI for accessing different modules, a shared database that all of them can use, and baseline security protections against obviously unsafe behavior.

There is still a lot to improve, especially around package trust and isolation, but the project is already useful enough to experiment with. From here, I want to keep expanding the package system, strengthen the security model, and eventually explore AI features and a mobile companion app.