PlanToCode
Retour à la documentation
Architecture

Technical Decisions & Tradeoffs

Why Tauri, SQLite, and a dedicated LLM proxy were chosen and what they cost.

•
10 min de lecture
•

Every architecture involves tradeoffs. This document explains the major technology choices in PlanToCode, what benefits they provide, and what costs or limitations they introduce.

Tradeoff matrix

Visual comparison of technology choices with their benefits and costs.

Technology tradeoff matrix
Click to expand
System architecture overview illustrating the technology stack decisions.

Tauri v2 for Desktop

Tauri provides a Rust backend with a web-based frontend, enabling cross-platform desktop apps with native performance and small binary sizes.

Benefits

  • Small binary size (~15MB vs 200MB+ for Electron)
  • Native Rust performance for file operations and job processing
  • Capability-based security model with fine-grained permissions
  • Single codebase for macOS, Windows, and Linux
  • Access to system APIs (PTY, keychain, notifications)

Tradeoffs

  • Smaller ecosystem than Electron
  • Rust learning curve for backend development
  • WebView rendering differences across platforms
  • Less mature tooling for debugging IPC issues

SQLite for Local Persistence

SQLite stores all local state including sessions, jobs, terminal output, and settings. This enables offline operation and fast queries.

Benefits

  • Zero-config embedded database
  • Fast queries for local data
  • Enables offline operation
  • Single file backup and restore
  • WAL mode for concurrent access

Tradeoffs

  • No built-in replication or sync
  • Large terminal logs can grow the database
  • Need manual schema migrations
  • Single-writer limitation (mitigated by WAL)

Implementation: Schema in consolidated_schema.sql with ~10 tables. Repositories provide typed access with rusqlite.

Dedicated LLM Proxy Server

All LLM requests route through a server proxy that manages API keys, normalizes requests, tracks usage, and handles billing.

Benefits

  • API keys never leave the server
  • Single request format for all providers
  • Centralized usage tracking and billing
  • Provider failover without client updates
  • Content filtering and rate limiting

Tradeoffs

  • Requires server infrastructure
  • Adds network latency to requests
  • Server becomes single point of failure
  • Need to maintain provider integrations

Implementation: Actix-Web server with handlers in server/src/handlers/proxy/. Transformers in provider_transformers/ normalize requests.

WebSocket Relay for Mobile

Desktop and mobile clients connect through a WebSocket relay for device linking, terminal streaming, and job synchronization.

Benefits

  • Real-time bidirectional communication
  • No direct P2P networking required
  • Works across NAT and firewalls
  • Supports multiple linked devices

Tradeoffs

  • Requires persistent server connections
  • Relay adds latency for large payloads
  • Connection management complexity
  • Need reconnection and heartbeat logic

Implementation: device_link_ws.rs implements the relay with session tracking, heartbeats, and PTC1 binary framing for terminal output.

Operational Consequences

  • Tauri: Need separate builds for each platform. CI/CD must cross-compile or use platform-specific runners.
  • SQLite: Database file grows with terminal output. May need periodic cleanup for long-running instances.
  • LLM Proxy: Server downtime blocks all LLM operations. Need monitoring and redundancy for production.
  • WebSocket: Reconnection logic adds complexity. Clients must handle connection drops gracefully.

Security Boundaries

The architecture creates clear security boundaries that limit exposure:

  • API keys stored in server vault, never sent to clients
  • JWT tokens validated on every request with JWKS rotation
  • Capability-based permissions limit filesystem access
  • Content sent to LLMs requires explicit user approval
  • Audit logs track all LLM requests with user context

When to Reconsider

These decisions may need revisiting if requirements change significantly:

  • If browser-only access is required, consider a web-based alternative to Tauri
  • If multi-device sync is critical, consider server-side job storage
  • If provider lock-in is acceptable, direct API calls may reduce latency
  • If mobile is primary, consider native apps instead of device linking