Choose implementation stack and app architecture

vince commented

2026-06-16 21:39:45 +02:00

Owner

Context:\nThe program should be local and probably not Python. Go is the current pragmatic default because it can ship as a single binary and handle HTTP, filesystem scanning, subprocesses, and SQLite well.\n\nRequirements:\n- Evaluate Go local web app versus Tauri desktop app.\n- Decide backend/runtime shape.\n- Decide whether UI is server-rendered HTML, lightweight JS, or a frontend build.\n- Decide metadata storage format, likely SQLite.\n- Define process model for long-running jobs such as downloads and ollama pulls.\n\nAcceptance criteria:\n- Architecture decision record exists.\n- Repo has a minimal skeleton for chosen stack.\n- Local run command is documented.

vince added the

architecture

mvp

labels 2026-06-16 21:42:28 +02:00

vince added this to the v0.1 MVP milestone 2026-06-16 21:42:28 +02:00

vince commented

2026-06-24 20:58:20 +02:00

Author

Owner

Architecture direction from backlog review:

Recommended v0.1 stack:

Go application, no Python.
Single local binary with subcommands such as serve, doctor, scan, and version.
Local HTTP server bound to 127.0.0.1 by default.
Server-rendered HTML using Go templates.
HTMX for partial updates, scan refreshes, and job progress where needed.
Plain CSS initially; no frontend build pipeline unless the UI later requires it.
SQLite for settings, scan snapshots, model metadata, job history, and logs.
Prefer a pure-Go SQLite driver such as modernc.org/sqlite to avoid CGO and simplify packaging.
YAML config because ComfyUI already uses extra_model_paths.yaml.

Architecture shape:

Keep Ollama and ComfyUI as separate provider adapters behind shared inventory, jobs, config, store, and web layers.
Ollama provider is API/service driven: detect binary, service status, API endpoint, inventory through Ollama API, mutations through Ollama API/CLI jobs later.
ComfyUI provider is filesystem/config driven: read extra_model_paths.yaml, resolve model roots, scan typed model folders, and treat files as the source of truth.
Do not fake a single operation model; normalize display and diagnostics, but keep actions provider-specific.

ADR should compare this against Tauri/Wails/Electron and explain why v0.1 starts as a localhost web app. Desktop packaging can be revisited post-MVP, likely via Wails if a shell is useful later.

Architecture direction from backlog review: Recommended v0.1 stack: - Go application, no Python. - Single local binary with subcommands such as serve, doctor, scan, and version. - Local HTTP server bound to 127.0.0.1 by default. - Server-rendered HTML using Go templates. - HTMX for partial updates, scan refreshes, and job progress where needed. - Plain CSS initially; no frontend build pipeline unless the UI later requires it. - SQLite for settings, scan snapshots, model metadata, job history, and logs. - Prefer a pure-Go SQLite driver such as modernc.org/sqlite to avoid CGO and simplify packaging. - YAML config because ComfyUI already uses extra_model_paths.yaml. Architecture shape: - Keep Ollama and ComfyUI as separate provider adapters behind shared inventory, jobs, config, store, and web layers. - Ollama provider is API/service driven: detect binary, service status, API endpoint, inventory through Ollama API, mutations through Ollama API/CLI jobs later. - ComfyUI provider is filesystem/config driven: read extra_model_paths.yaml, resolve model roots, scan typed model folders, and treat files as the source of truth. - Do not fake a single operation model; normalize display and diagnostics, but keep actions provider-specific. ADR should compare this against Tauri/Wails/Electron and explain why v0.1 starts as a localhost web app. Desktop packaging can be revisited post-MVP, likely via Wails if a shell is useful later.

Rows
Columns

Choose implementation stack and app architecture #2