Phase 3: Worker-Migration zu Go evaluieren

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Depends on

#323 Phase 2: Backend in Go implementieren

customable/claude-mem

Reference

customable/claude-mem#324

jack commented

2026-01-26 08:26:25 +00:00

Owner

Ziel

Evaluieren, ob der Worker (packages/worker) von TypeScript nach Go migriert werden sollte - und wenn ja, wann.

Kontext

Der Worker ist aktuell fast rein I/O-bound (AI-API-Calls, WebSocket-Kommunikation). Go bringt hier keinen signifikanten Performance-Vorteil. Diese Phase wird nur relevant, wenn sich die Anforderungen ändern.

Wann wird Migration sinnvoll?

Lokale Embedding-Generierung wird CPU-intensiv (statt API-Calls)
Batch-Verarbeitung großer Datenmengen nötig
Worker soll als eigenständiger Service deployed werden (nicht im Plugin)
Memory-Footprint des Workers wird zum Problem
Einheitlicher Tech-Stack (Backend + Worker beide Go) wird gewünscht

Aktueller Worker-Scope (~7.100 LOC)

Komponente	LOC	Typ	Go-Vorteil?
AI Agents (5 Provider)	1.016	I/O-bound	Nein
Task Handlers (8 Types)	1.525	I/O-bound	Nein
WebSocket Client	370	I/O-bound	Marginal
Embedding Providers	576	I/O oder CPU	Nur bei lokal
Vector DB Client	460	I/O-bound	Nein
XML Parser	198	CPU-bound	Marginal
Retry Logic	141	CPU-bound	Nein

Wenn Migration: Aufgaben

AI-Provider-Interfaces in Go (Anthropic, Mistral, OpenAI, Gemini, OpenRouter)
WebSocket-Client für Backend-Kommunikation
Task-Handler-Logik portieren
XML/Response-Parser
Embedding-Provider (lokal: go-onnxruntime statt @xenova/transformers)
Qdrant-Client (Go SDK verfügbar)

Entscheidungskriterien

Kriterium	Für Migration	Gegen Migration
Performance	Nur bei CPU-bound Tasks	I/O-bound → kein Unterschied
Memory	~80MB → ~10MB	Akzeptabel für Dev-Tool
Maintenance	Ein Tech-Stack	Rewrite-Aufwand
AI SDKs	Go-SDKs verfügbar	TS-SDKs ausgereifter
Deployment	Single Binary mit Backend	Funktioniert auch so

Empfehlung

Vorerst nicht migrieren. Erst evaluieren wenn einer der Trigger-Punkte oben eintritt. Der Worker kann problemlos weiter in TypeScript laufen und über WebSocket mit einem Go-Backend kommunizieren.

Teil von

#321 Backend-Migration: Inkrementeller Wechsel von Node/TypeScript zu Go

## Ziel Evaluieren, ob der Worker (packages/worker) von TypeScript nach Go migriert werden sollte - und wenn ja, wann. ## Kontext Der Worker ist aktuell fast rein I/O-bound (AI-API-Calls, WebSocket-Kommunikation). Go bringt hier keinen signifikanten Performance-Vorteil. Diese Phase wird nur relevant, wenn sich die Anforderungen ändern. ## Wann wird Migration sinnvoll? - [ ] Lokale Embedding-Generierung wird CPU-intensiv (statt API-Calls) - [ ] Batch-Verarbeitung großer Datenmengen nötig - [ ] Worker soll als eigenständiger Service deployed werden (nicht im Plugin) - [ ] Memory-Footprint des Workers wird zum Problem - [ ] Einheitlicher Tech-Stack (Backend + Worker beide Go) wird gewünscht ## Aktueller Worker-Scope (~7.100 LOC) | Komponente | LOC | Typ | Go-Vorteil? | |-----------|-----|-----|-------------| | AI Agents (5 Provider) | 1.016 | I/O-bound | Nein | | Task Handlers (8 Types) | 1.525 | I/O-bound | Nein | | WebSocket Client | 370 | I/O-bound | Marginal | | Embedding Providers | 576 | I/O oder CPU | Nur bei lokal | | Vector DB Client | 460 | I/O-bound | Nein | | XML Parser | 198 | CPU-bound | Marginal | | Retry Logic | 141 | CPU-bound | Nein | ## Wenn Migration: Aufgaben - [ ] AI-Provider-Interfaces in Go (Anthropic, Mistral, OpenAI, Gemini, OpenRouter) - [ ] WebSocket-Client für Backend-Kommunikation - [ ] Task-Handler-Logik portieren - [ ] XML/Response-Parser - [ ] Embedding-Provider (lokal: go-onnxruntime statt @xenova/transformers) - [ ] Qdrant-Client (Go SDK verfügbar) ## Entscheidungskriterien | Kriterium | Für Migration | Gegen Migration | |-----------|--------------|-----------------| | Performance | Nur bei CPU-bound Tasks | I/O-bound → kein Unterschied | | Memory | ~80MB → ~10MB | Akzeptabel für Dev-Tool | | Maintenance | Ein Tech-Stack | Rewrite-Aufwand | | AI SDKs | Go-SDKs verfügbar | TS-SDKs ausgereifter | | Deployment | Single Binary mit Backend | Funktioniert auch so | ## Empfehlung **Vorerst nicht migrieren.** Erst evaluieren wenn einer der Trigger-Punkte oben eintritt. Der Worker kann problemlos weiter in TypeScript laufen und über WebSocket mit einem Go-Backend kommunizieren. ## Teil von #321 Backend-Migration: Inkrementeller Wechsel von Node/TypeScript zu Go

jack added the

labels

2026-01-26 08:26:26 +00:00

jack added a new dependency

2026-01-26 08:26:37 +00:00

jack closed this issue

2026-01-26 08:32:47 +00:00

Rows
Columns

Phase 3: Worker-Migration zu Go evaluieren #324