Desktop Client

Built to move as fast as you do

A home management system is only as useful as the interface you live in every day. Casabeza's desktop client is written in Rust — compiled to a native binary, with zero runtime dependencies and an immediate-mode UI that responds without delay.

Native, not a web app

The desktop client (cbz-desktop) ships as a single compiled binary. No Electron. No embedded browser. No 200MB download with a bundled Chromium. The entire application fits in a few megabytes, starts in under a second, and never holds memory it doesn't need.

It's packaged as a .deb for Linux and installs cleanly alongside your other system software. One file. One entry in your package manager. Done.

Nine modular service clients

Underneath the UI, nine purpose-built async HTTP clients handle communication with Casabeza's backend services — each with a single responsibility, each optimized for its domain:

• Inventory — Items, containers, locations, labels, CTags, document management
• Numerics — Price tracking, varieties, vendors, purchase history
• Projects — Project records, logs, item associations
• Bills — Shared expenses, payment workflows, scheduling
• Lists — Shopping and checklist templates, live instances
• Tasks — Maintenance schedules, task libraries, completion records
• Onboarding — House configuration and setup flows
• Splashy — Authentication, session management, house discovery

Every client is async, uses connection pooling, and handles errors without blocking the UI thread. The rendering loop never waits on a network call.

Real-time MQTT integration

Fixed readers and the Android scanner publish scan events to an MQTT broker. The desktop client subscribes and responds in real time: open the item record, log a location change, increment a stock count — all triggered by a single scan with no manual navigation.

Reader channels are configurable from within the desktop client. A mounted reader at a storage shelf can have its ingress and egress actions, scope, and label type set without touching the backend directly.

Offline-first data model

Inventory data, labels, locations, projects, and task notifications are cached locally. Opening the application loads from disk; the network syncs changes. On a slow or interrupted connection, the interface remains useful. Delta-refresh strategies minimise bandwidth once data is loaded.

Image and document assets download in a background worker pool. They appear when ready and are cached for subsequent sessions — no waiting, no re-fetching.

Domain-first interface

The UI is organized around the domains that matter: inventory hierarchy, project logs, price history charts, task notifications, and shopping lists. Each area has dedicated views built for how that data is actually used — not generic CRUD screens adapted from a web form.

Chart rendering is built in (egui_plot). Image and PDF documents open inline — no external viewer required. Custom tags (CTags) with colour coding give items a visual taxonomy that's visible at a glance.

A note on speed

Every component in the stack was chosen for low overhead:

• egui — immediate-mode rendering with no retained state complexity
• tokio — multi-threaded async runtime, no thread-per-request
• reqwest + rustls — TLS without a system OpenSSL dependency
• serde — zero-copy JSON deserialisation into typed structures

The result is an application that feels instantaneous. Not because hardware is fast — it is — but because nothing in the stack wastes cycles.

← Back to all features