Architektur

Prozesse und Vertrauensgrenzen

Tauri verfügt über eine native Fensterintegration, sichere Anmeldeinformationsbefehle, Menüs, Updates und einen Sidecar-Lebenszyklus. Seine Webansicht führt die SolidJS-Anwendung aus. Der kompilierte Bun-Sidecar öffnet die Datenbank und stellt HTTP bereit 127.0.0.1 mit einem vom Betriebssystem zugewiesenen Port. Das Frontend öffnet SQLite nicht.

Der Einstiegspunkt des Sidecars ist apps/sidecar/src/main.ts. Es erstellt den HTTP-Server, erstellt die Anwendungsschichten und prüft /api/healthund gibt dann ein JSON-Bereitschaftsereignis aus, das den ausgewählten Port enthält. Protokolle werden an stderr weitergeleitet, sodass stdout weiterhin für das Shell-Protokoll verfügbar bleibt.

Der mobile Begleiter erreicht ein explizit gekoppeltes Desktop-Gateway. Seine nativen Transport- und Geräteanmeldeinformationen sind von der Loopback-Verbindung der Desktop-Webansicht getrennt. Der Dokumentations-Worker ist eine separate Bereitstellung und hat keine implizite Verbindung zum Desktop eines Benutzers.

Bibliotheksabhängigkeiten

@cadcamfun/core enthält CAD-, Zeichnungs- und CAM-Berechnungen. Für Schemata und Grenzintegration hängt es vom Effekt ab; Algorithmusschleifen sind gewöhnliches TypeScript. @cadcamfun/api importiert Kerntypen und Schemata, um HTTP-Eingaben, -Ausgaben, -Fehler und -Streams zu deklarieren.

@cadcamfun/db besitzt den Anwendungsdatenbankdienst, das Schema und die Migrationslogik. Der Sidecar kombiniert es mit Kern-, API-, KI-, Plugin-SDK-, VCS- und Workflow-Paketen. Seine Repositorys nutzen den Datenbankdienst; Handler delegieren an Repositorys und Dienste.

Der Desktop importiert beide @cadcamfun/api und @cadcamfun/core. Es nutzt die API zur Laufzeit über einen Effect-Client und nutzt die Kerngeometrie in CAD/CAM-Features und dem Ansichtsfenster. Mobile ist vom API-Paket abhängig und verpackt Begleitanfragen in seinem Client. Das eigenständige Nikcli-Plugin erkennt den Aktionskatalog der laufenden Anwendung über HTTP, anstatt Backend-Implementierungen zu importieren.

Lebenszyklus einer HTTP-Anfrage

1. Die Webansicht erhält die Sidecar-Verbindung von der nativen Shell.
2. apps/desktop/src/app/client.ts erstellt einen Effect HttpApi-Client mit Inhaberautorisierung und einem optionalen Kontositzungstoken. packages/api/src/client.ts stellt einen wiederverwendbaren Vertragskunden für andere Verbraucher bereit.
3. apps/sidecar/src/layers.ts montiert ServedApi, handler, Autorisierung, CORS und Shared-Service-Schichten.
4. Der Handler validiert Vertragseingaben, löst Dienste auf, führt Berechnungen oder Persistenz durch und gibt die deklarierte Erfolgs- oder Fehlerdarstellung zurück. Streaming-Endpunkte behalten ihr deklariertes Stream-Protokoll bei.

CORS erlaubt die Verwendung von Tauri-Produktionsursprüngen und HTTP-Loopback-Ursprüngen in der Entwicklung. Sie ersetzt nicht die Autorisierung. Die API stellt mehrere Antwortumschlagsstile bereit; Verbraucher müssen dem Schema jedes Endpunkts folgen und dürfen nicht davon ausgehen, dass jede Antwort die gleiche Form hat.

Servicelebenszyklus und Speicherung

Effektschichten erwerben die Datenbank und gemeinsam genutzte Dienste innerhalb des Anwendungsbereichs. Die Datenbankschicht erstellt ihr übergeordnetes Verzeichnis, aktiviert WAL und Fremdschlüssel, wendet optional Migrationen an und umschließt Abfragefehler mit einem Operationsnamen. Die Finalisierung versucht einen WAL-Prüfpunkt zu kürzen und schließt das SQLite-Handle.

Der DatabaseLive ebene wählt dataDir/cadcamfun.db. Um Migrationen beim Start anwenden zu können, muss ein Migrationsordner bereitgestellt werden. KI-Anmeldeinformationen, Plugin-Status, VCS-Objekte, Workflow-Ausführung und Dateispeicherung werden über ihre jeweiligen Serviceschnittstellen verwaltet; Einzelheiten zur Speicherung sind auf den jeweiligen Modulseiten beschrieben.

Das örtliche Studio in packages/web/script/studio-server.ts ist ein zusätzlicher Bunprozess. Es öffnet direkt eine konfigurierte vorhandene Anwendungsdatenbank und stellt authentifizierte Übersichtsdaten am Loopback-Port 4396 bereit. Seine Entwicklungs-Proxy- und Cookie-Sitzungen sind unabhängig von der Tauri-Sidecar-Verbindung.

Live-Projektereignisse (Pull-Requests, Commits, Workflow-Ausführungen und Assistentensitzungsphasen) werden über einen In-Process-Ereignisdienst veröffentlicht. A new subscriber first receives up to the 20 most recent matching events and then live ones, optionally filtered by project and event type (apps/sidecar/src/services/live-events.ts).

Erweiterungsgrenzen

Es gibt zwei Plugin-Integrationen. Das Anwendungs-Plugin-SDK definiert Manifeste, Funktionen, Aktivierung und Hostverträge. Die Nikcli-Brücke stellt registrierte CAD/CAM-Aktionen einem externen Assistenten zur Verfügung. Die Installation eines Plugins über eine HTTP-Registrierungsroute ist ein von der Aktivierung eines Moduls im Laufzeithost getrennter Vorgang.

Workflow-Analyse und -Planung live in packages/workflow. Servicegestützte Schritte werden von Sidecar-Schichten registriert, während reine Projekt- und CAM-Schritte mit ihren bereitgestellten Eingaben ausgeführt werden können. VCS berechnet Objekt-Hashes, Diffs, Zusammenführungen und GitHub-Transportoperationen in seiner Bibliothek; Sidecar-Dienste verbinden diese Vorgänge mit der Projektpersistenz.

Der Webdokumentationsassistent ruft gerenderte Dokumentation ab und kann Leitfadenartefakte veröffentlichen, wenn der Speicher konfiguriert ist. Es beantwortet Fragen zur Dokumentation; Der lokale Projektzugriff der CAD/CAM-Anwendung wird nicht übernommen.

Verbindungs- und Anmeldegrenzen

Die Autorisierung ist geschichtet. Das Weitergeben der Träger-Middleware beweist nicht das Eigentum an einer bestimmten Zeichnung oder einem bestimmten Projekt; Handler und Repositorys überprüfen diese Ressourcen. Durch die Kopplung wird das Telefon ebenfalls nicht zu einem uneingeschränkten Sidecar-Client. Konsultieren Sie die spezifischen Endpunkt- und Companion-Richtlinien, bevor Sie einen Berechtigungsnachweis auswählen.

Der Autorisierungsadapter ist apps/sidecar/src/http/authorization.ts. Begleiter- und Brückenentscheidungen leben in ihren eigenen Diensten. Durch die Trennung dieser Pfade kann ein verlorenes Gerät oder ein Integrationstoken widerrufen werden, ohne dass das Geheimnis eines KI-Anbieters ersetzt wird.

Fehlerisolierung

Fehler vor dem Bereitschaftsereignis gehören zur Sidecar-Initialisierung: Konfiguration, Datenbank-Upgrade, Dienstaufbau oder HTTP-Start. Fehler nach der Bereitschaft können spezifisch für einen Anbieter, einen Dateisystemvorgang, einen Endpunkt oder eine Clientsitzung sein. Der Lebenszyklus der Shell und das Verbindungswiederholungsbudget der Webansicht sind unterschiedlich. Überprüfen Sie beide, wenn ein Neustart den Überwachungsport ändert.

Ein getrennter KI-Stream stoppt nicht unbedingt seine serverseitige Konversation. Stellen Sie den Sitzungsstatus wieder her, bevor Sie eine Bearbeitungsanweisung erneut senden. Ein fehlgeschlagener Workflow setzt seinen auslösenden Commit nicht zurück. Ein erfolgloser Remote-Push löscht den lokalen Verlauf nicht. Diese Unterscheidungen verhindern, dass ein Netzwerkausfall so behandelt wird, als ob nie ein dauerhafter Vorgang stattgefunden hätte.

Notieren Sie für eine fehlgeschlagene API-Anfrage deren Methode, Pfad, Status, Endpunkt-ID und relevante nicht geheime Kennungen. Vergleichen Sie das Laufen /api/openapi.json mit dem schnappschuss des Dokumentationsvertrags wenn Client- und Serverversionen unterschiedlich sind. Vermeiden Sie die Fehlerbehebung mit einem Token aus einem früheren Sidecar-Start.

Architektur-Snapshot nach Quellpfad

Trace: vom Start bis zur ersten Anfrage

1. Tauri beginnt und der Vorgesetzte kommt herein sidecar.rs generiert einen zufälligen Token.
2. Es spawnt sidecar-<triple> mit CADCAMFUN_TOKEN, CADCAMFUN_DATA_DIR und CADCAMFUN_MIGRATIONS_DIR.
3. Der Sidecar liest seine Konfiguration, öffnet SQLite (WAL, Fremdschlüssel), sichert und migriert bei Bedarf und erstellt seine Serviceschichten.
4. Es bindet 127.0.0.1 auf einem kurzlebigen Port und gibt eine JSON-bereite Zeile auf stdout aus. Der Supervisor wartet bis zu 60 s darauf.
5. Der Vorgesetzte sendet sidecar-status { state: "ready", port }; die Webview-Aufrufe get_sidecar_endpoint für { baseUrl, token }.
6. Die Webansicht wird erstellt ApiClient.layer({ baseUrl, token }) und beginnt mit dem Laden von Projekten.

Wenn der Sidecar austritt, startet ihn der Supervisor einmal neu und gibt den neuen Port bekannt; ein zweiter Fehler belässt den Status bei failed. Beim Beenden schreibt der Supervisor die Shutdown-Zeile, wartet 2 s und erntet dann den Prozess; Die Datenbankschicht setzt einen Prüfpunkt für die WAL, wenn ihr Gültigkeitsbereich geschlossen wird.

Spur: eine Herstellungsanfrage

1. Der CAM-Arbeitsbereich erfasst die Zeichnungselemente sowie Rohmaterialien und Aufrufe POST /api/toolpaths/manufacture.
2. Die Träger-Middleware lässt die Anfrage zu; Der Körper wird dagegen entschlüsselt CamKernelRequest.
3. runKernelRequest in services/cam-program.ts anrufe cam.kernel.jobOfSnapshot; vorbereitungsprobleme werden zu einem 400.
4. cam.kernel.runJob plant oder verfolgt Vorgänge, berechnet Schnittdaten, generiert Werkzeugwege, gibt NC für den Dialekt der Maschine ein und gibt sie auf Voxel-Daten wieder, um Ansprüche zu bewerten.
5. Das Ergebnis wird dagegen dekodiert CamKernelResult und kehrte zurück. Es wird nichts gespeichert, bis der Kunde einen Werkzeugweg mit einem tragbaren Dokument speichert. An diesem Punkt führt der Sidecar die erfasste Anforderung erneut aus und vergleicht sie.

In 3D