Framework choice: Tauri vs Electron vs PWA/Capacitor for Find

[Abhash-Chakraborty]

Goal

Choose a practical packaging direction for Find without losing the current Next.js frontend investment.

Tauri option

Pros:

• Smaller desktop shell than Electron because it uses the system WebView.
• Good fit for a local-first app if we use Rust for process management and secure native capabilities.
• Tauri docs support Next.js static export patterns and desktop release workflows.

Risks:

• The frontend may need static export compatibility work.
• Python backend and ML sidecars need careful process lifecycle handling.
• Mobile support exists, but the Find backend/ML stack is much heavier than a normal mobile app.

Electron option

Pros:

• Mature desktop ecosystem.
• Electron Builder supports Windows NSIS, macOS DMG, Linux AppImage/deb/rpm style packaging and updater workflows.
• Easier Node-based process orchestration.

Risks:

• Larger app footprint because Chromium is bundled.
• Find is already heavy because of ML models, so extra shell size matters.

PWA/Capacitor option

Pros:

• Useful for mobile companion experience.
• Can reuse web UI concepts.
• Capacitor is designed to wrap web apps with native Android/iOS projects and plugins.

Risks:

• Not a good fit for bundling PostgreSQL, Redis, MinIO, Python workers, and large ML models directly on mobile.
• Likely better as a companion or remote-to-user-owned-device experience first.

Suggested direction

• Desktop: investigate Tauri first, with Electron as fallback if sidecar/runtime complexity blocks us.
• Mobile: start as PWA/Capacitor companion, not full local ML.
• Keep all cloud/server behavior optional and explicit.

Decision outputs needed

• A short ADR in docs/adr/.
• A prototype branch or issue proving the desktop shell can start and stop local services.
• A clear statement of what remains local by default.