Architektur
Wie LastBrowser aufgebaut ist — Electron-Shell, Python-Backend, IPC-Schicht, Datenfluss und Moduldesign.
Inhaltsverzeichnis
Überblick auf hoher Ebene
LastBrowser ist eine Zwei-Prozess-Anwendung, die eine Electron-Shell (Frontend-UI, native OS-Integration) mit einem Python-Backend (KI-Agentenlogik, WebUI-Server) kombiniert. Die beiden Prozesse kommunizieren über HTTP und einen lokalen Port.
Electron-Hauptprozess
Der Hauptprozess (native/main.js) ist der Anwendungsorchestrator. Er verwaltet:
- Fenstererstellung: Erstellt das
BrowserWindowmit versteckter Titelleiste (benutzerdefiniert rahmenlos), Seitenleistenintegration und WebContentsView-Verwaltung. - Server-Lebenszyklus: Startet/stoppt den Python-WebUI-Backend-Server über
server-launcher.js. Handhabt das saubere Herunterfahren beim Beenden der App. - System Tray: Verwaltet Tray-Symbol, Kontextmenü (Anzeigen, Server neu starten, Beenden) und das Verhalten beim Minimieren in die Taskleiste.
- IPC-Router: Die gesamte Kommunikation zwischen Renderer und Hauptprozess erfolgt über einen zentralisierten IPC-Router (
src/main/ipc/router.js). - Globale Tastenkürzel: Registriert
Strg+K(Befehlspalette),Strg+Umschalt+M(Alle stummschalten),Strg+B(Seitenleiste umschalten). - WebViews: Verwaltet
WebContentsView-Instanzen für Browser-Tabs mit Erstellungs-/Lösch-/Anhäng-Lebenszyklus.
Modulsystem
Der Hauptprozess organisiert die Funktionalität durch ein Manager-Muster. Jeder Manager ist ein eigenständiges Modul:
Jeder Manager folgt einem einheitlichen Muster:
- Speichert Daten über die Datenbank-Store-Abstraktion
- Exportiert eine saubere API von Funktionen
- Handhabt die auf den Arbeitsbereich bezogene Isolierung, wo zutreffend
IPC-Kommunikation
Die gesamte Kommunikation zwischen Renderer und Hauptprozess verwendet das contextBridge + ipcMain.handle / ipcRenderer.invoke-Muster von Electron. Das IPC-Kanalsystem ist in src/shared/constants.js mit ~150+ Kanälen definiert, die nach Domänen organisiert sind:
// IPC-Kanalorganisation (aus src/shared/constants.js) IPC.WORKSPACE_LIST, .WORKSPACE_CREATE, .WORKSPACE_DELETE... IPC.TAB_CREATE, .TAB_CLOSE, .TAB_SUSPEND, .TAB_RESTORE... IPC.AGENT_LIST, .AGENT_INVOKE, .AGENT_RESPONSE... IPC.APP_LIST, .APP_CREATE, .APP_MUTE, .APP_SLEEP... IPC.SPLIT_VIEW_CREATE, .SPLIT_VIEW_RESIZE... IPC.FOCUS_START, .FOCUS_STOP, .FOCUS_STATUS... IPC.KANBAN_CREATE, .KANBAN_MOVE, .KANBAN_WIP... IPC.TAB_EXEC_JS, .TAB_SCREENSHOT, .TAB_GET_CONTENT
Sicherheit: contextIsolation: true, nodeIntegration: false. Alle Node.js-APIs werden über preload.js mit expliziter Whitelist freigegeben.
Datenspeicherung
LastBrowser verwendet sql.js (SQLite kompiliert zu WebAssembly via Emscripten) für alle persistenten Daten:
- Sammlungen: Tabs, Arbeitsbereiche, Agenten, Einstellungen, Kanban-Boards/Spalten/Karten, Fokus-Sitzungen, geschlossene Tabs, App-Konten, Worker-Jobs, Aufgaben, Ablenkungsregeln.
- Datenbank-Speicherort: Gespeichert im App-Datenverzeichnis des Benutzers (Electrons
app.getPath('userData')). - Schema: Sammlungsbasierter Dokumentenspeicher auf Basis von SQLite. Jede "Sammlung" ist entweder eine Tabelle oder eine JSON-Dokumentspalte.
- Migrationen: Verwaltet von
src/main/database/migrations.jsfür die Schemaentwicklung zwischen Versionen.
Python-Backend
Das Python-Backend (server.py) stellt die Hermes-WebUI bereit – die KI-Agenten-Schnittstelle, die LastBrowser umschließt:
- Framework: Python-HTTP-Server (FastAPI oder ähnlich), der die WebUI auf
localhost:7889bereitstellt. - Server-Start:
server-launcher.jsstartet den Python-Prozess, wartet auf seine Bereitschaft und verwaltet seinen Lebenszyklus. Im Entwicklungsmodus befindet er sich im Projektstamm; in der Produktion wird er alsextraResources/webui/gebündelt. - HTTP-API: REST-Endpunkte für Agenteninteraktion, Sitzungsverwaltung, Skill-Operationen usw.
- Statische Dateien: Das WebUI-Frontend wird aus dem
static/-Verzeichnis bereitgestellt.
Build & Paketierung
LastBrowser verwendet electron-builder v25 für die Paketierung und Verteilung:
native/ ├── package.json # Abhängigkeiten + Build-Skripte ├── electron-builder.config.js # electron-builder-Konfiguration ├── main.js # App-Einstiegspunkt ├── preload.js # Sicherheitsbrücke ├── server-launcher.js # Python-Backend-Lebenszyklus ├── assets/ # Symbole (PNG, ICO, SVG) └── src/ # Quellmodule
Windows-Build:
- Ziel: NSIS-Installer (x64) oder portable .exe
- Python-Backend gebündelt als
extraResources/webui/ - Auto-Updater konfiguriert für GitHub-Releases
- GitHub Actions CI baut auf
windows-latest
Sicherheitsmodell
- Kontextisolierung: Aktiviert. Der Renderer hat keinen direkten Zugriff auf Node.js- oder Electron-APIs.
- Preload-Brücke: Nur explizit auf die Whitelist gesetzte IPC-Kanäle werden über
contextBridge.exposeInMainWorldfreigegeben. - Sandbox: Deaktiviert (erforderlich für die WebContentsView-Funktionalität), aber durch Kontextisolierung abgemildert.
- Sitzungspartitionen: Jeder Arbeitsbereich und jede App erhält eine eigene
persist:-Sitzungspartition, um Cross-Origin-Datenlecks zu verhindern. - Navigationskontrolle: Externe Links werden im Systembrowser geöffnet, niemals im App-Fenster.
- Werbeblocker: Optionaler integrierter Werbeblocker mit Filterlisten.
- Cache: Vom Benutzer initiierte Cache-Leerung pro App oder global. Cookie-Steuerung (Drittanbieter blockieren).