Why Banger Uses a Rust Service and Client SDK

Banger is not just a remote API with a desktop window in front of it.

The app has to keep mailbox state fast, coordinate Gmail history, stage attachments, process provider updates, expose local commands, and give trusted local AI tools a controlled way to work with email. Those jobs are too important to leave tangled inside a UI process.

So the current architecture has a clear local boundary:

a Rust service owns the runtime work, and a Rust client SDK gives every local client the same contract.

That boundary is now one of the most important pieces of the product.

Runtime work needs a real owner

Email clients are stateful in ways that ordinary web apps are not.

A user expects the thread list to stay responsive while sync continues. A provider event might arrive while the app is rendering. A local command might need to inspect state without launching the full interface. An AI workflow might need to propose an action without receiving direct database access.

Those responsibilities need one stable owner:

• mailbox sync
• local mailbox database access
• Gmail history coordination
• provider update processing
• attachment staging
• local command handling
• service health checks
• runtime compatibility checks
• permissioned local access for trusted tooling

The Rust service gives those jobs a single home.

The UI should stay focused

The UI should render state, accept input, and keep the product understandable.

It should not be the only place where mailbox sync, service ownership, background coordination, and local automation live. If every app surface rebuilt its own runtime path, small behavior differences would turn into data bugs and confusing recovery states.

The service boundary lets the app ask for product state and operations without owning every detail underneath. That keeps the interface smaller, keeps background work independent, and gives local integrations a controlled path into Banger.

Why Rust

The runtime needs predictable binaries, strong type boundaries, good concurrency tools, and a practical path to native integration. Rust fits that shape well.

The service can own long-running operational work without depending on a UI host. It can ship as a local binary, manage state consistently, expose a narrow protocol, and keep correctness-sensitive code close to the data it protects.

Rust also gives us a good foundation for cross-language bindings. That matters because Banger has multiple local consumers, and they should not each carry a separate hand-written service client.

The client SDK is the contract

A service boundary only helps if clients use it consistently.

That is why Banger has a Rust client SDK. The SDK is the typed local contract for talking to the service. It hides startup details, transport details, compatibility checks, request formatting, and process ownership behind operations that make sense to the product.

The desktop app, CLI, native shells, and local AI tooling can all use the same client surface instead of each one growing a partial service implementation.

That keeps the boundary honest. The service owns runtime behavior. The SDK owns client access. The app owns interaction.

Local AI tooling needs a narrow bridge

AI tooling is a good test for this architecture.

A local agent should not receive raw access to private files or internal databases just because it runs on the same machine. It should talk to a product-aware boundary that knows about mailboxes, threads, approvals, permissions, and workspace context.

The Rust service and client SDK give Banger that bridge.

An AI workflow can inspect the right state, propose the right action, and remain inside the same permission model as the rest of the product. Sensitive operations can stay explicit. Credentials can stay scoped. The user can still understand what is happening.

Compatibility matters

Local services fail in different ways from web requests.

The app and runtime can get out of sync during development, partial upgrades, restarts, or failed launches. A clear SDK boundary gives us a place to detect those mismatches early and recover with useful errors instead of letting the app fail later in confusing ways.

That kind of compatibility work is not decorative. It is what makes a local app feel stable.

Native integration still matters

The Rust boundary does not remove platform work.

Each operating system still has its own windowing behavior, startup model, secure storage expectations, notification rules, packaging constraints, and native APIs. Banger still needs platform-specific engineering where users can feel the difference.

The important change is that platform work no longer has to own the whole runtime. Native app surfaces can focus on the operating system. The Rust service can focus on local email operations. The SDK connects the two.

The shape we want

Banger’s local architecture is now deliberately split:

• App surfaces own interaction.
• The Rust service owns runtime work.
• The Rust client SDK owns access to that runtime.
• Native integration owns the operating-system edge.

That split is less glamorous than a one-layer architecture, but it is much easier to trust.

Email is operational infrastructure. The local architecture should treat it that way.