Phase 2: Backend in Go implementieren #323

Closed
opened 2026-01-26 08:26:24 +00:00 by jack · 0 comments
Owner

Ziel

Das Backend (packages/backend + packages/database) als Go-Service neu implementieren, basierend auf der OpenAPI-Spec aus Phase 1.

Voraussetzungen

  • #322 Phase 1: OpenAPI-Contract abgeschlossen
  • Go-Toolchain und Projekt-Setup

Tech-Stack (Vorschlag)

Komponente Go-Library Ersetzt
HTTP Router chi oder echo Express
Database sqlc + pgx/go-sqlite3 MikroORM
WebSocket gorilla/websocket oder nhooyr/websocket ws
SSE net/http nativ Custom Express-Handler
Rate Limiting golang.org/x/time/rate express-rate-limit
Metrics prometheus/client_golang prom-client
Logging slog (stdlib) Custom Logger
Config envconfig oder viper Custom Settings
Migrations goose oder golang-migrate MikroORM Migrations

Aufgaben

1. Projekt-Setup

  • Go-Modul initialisieren (go mod init)
  • Projektstruktur: cmd/, internal/, pkg/
  • CI/CD für Go-Build
  • Makefile / Taskfile

2. Database-Layer

  • SQLite-Schema aus bestehenden Migrations übernehmen
  • sqlc-Queries für alle Repository-Methoden schreiben
  • FTS5-Setup (Virtual Tables, Triggers) als SQL-Migrations
  • Multi-DB-Support evaluieren (SQLite + PostgreSQL)

3. Core Services

  • HTTP-Server mit allen Endpoints (aus OpenAPI generiert)
  • WebSocket-Hub (Worker-Connections, Auth, Heartbeat)
  • SSE-Broadcaster (Event-Broadcasting an UI/Writer)
  • Task-Dispatcher (Polling, Capability-Matching, Backoff)
  • Session-Service (Lifecycle, Prompt-Tracking)
  • Task-Service (Queue, Backpressure, Deduplication)

4. Middleware

  • Auth (Bearer Token + Localhost-Bypass)
  • Rate Limiting (Global + Per-Endpoint)
  • Request-ID Tracking
  • Structured Logging
  • Prometheus Metrics
  • CORS

5. Migration & Testing

  • Parallelbetrieb: Go-Backend neben Node-Backend testen
  • API-Kompatibilitätstests gegen OpenAPI-Spec
  • Load-Tests: Memory, Connections, Throughput vergleichen
  • Hooks, Worker und UI gegen Go-Backend testen

6. Deployment

  • Single Binary Build
  • Docker-Image (multi-stage, ~20MB)
  • Systemd-Service-Datei anpassen
  • Startup-Logik im Plugin anpassen (Go-Binary statt Node)

Erwartete Verbesserungen

Metrik Node (aktuell) Go (erwartet)
Memory (Backend) ~100MB ~15MB
Startup ~2-3s <100ms
Binary Size N/A (Node Runtime) ~15-20MB
WS Connections Hunderte (Event-Loop) 100k+ (Goroutines)
Concurrency Single-Thread Multi-Core nativ

Risiken

  • Multi-DB-Support (SQLite + PostgreSQL) ist in Go ohne ORM aufwändiger
  • FTS5-Queries müssen manuell getestet werden (kein ORM-Abstraktionslayer)
  • Go-Error-Handling ist verbose verglichen mit TypeScript try/catch
  • Lernkurve für Go-Idiome (channels, goroutines, interfaces)

Teil von

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

## Ziel Das Backend (packages/backend + packages/database) als Go-Service neu implementieren, basierend auf der OpenAPI-Spec aus Phase 1. ## Voraussetzungen - [ ] #322 Phase 1: OpenAPI-Contract abgeschlossen - [ ] Go-Toolchain und Projekt-Setup ## Tech-Stack (Vorschlag) | Komponente | Go-Library | Ersetzt | |------------|-----------|---------| | HTTP Router | `chi` oder `echo` | Express | | Database | `sqlc` + `pgx`/`go-sqlite3` | MikroORM | | WebSocket | `gorilla/websocket` oder `nhooyr/websocket` | ws | | SSE | `net/http` nativ | Custom Express-Handler | | Rate Limiting | `golang.org/x/time/rate` | express-rate-limit | | Metrics | `prometheus/client_golang` | prom-client | | Logging | `slog` (stdlib) | Custom Logger | | Config | `envconfig` oder `viper` | Custom Settings | | Migrations | `goose` oder `golang-migrate` | MikroORM Migrations | ## Aufgaben ### 1. Projekt-Setup - [ ] Go-Modul initialisieren (`go mod init`) - [ ] Projektstruktur: `cmd/`, `internal/`, `pkg/` - [ ] CI/CD für Go-Build - [ ] Makefile / Taskfile ### 2. Database-Layer - [ ] SQLite-Schema aus bestehenden Migrations übernehmen - [ ] `sqlc`-Queries für alle Repository-Methoden schreiben - [ ] FTS5-Setup (Virtual Tables, Triggers) als SQL-Migrations - [ ] Multi-DB-Support evaluieren (SQLite + PostgreSQL) ### 3. Core Services - [ ] HTTP-Server mit allen Endpoints (aus OpenAPI generiert) - [ ] WebSocket-Hub (Worker-Connections, Auth, Heartbeat) - [ ] SSE-Broadcaster (Event-Broadcasting an UI/Writer) - [ ] Task-Dispatcher (Polling, Capability-Matching, Backoff) - [ ] Session-Service (Lifecycle, Prompt-Tracking) - [ ] Task-Service (Queue, Backpressure, Deduplication) ### 4. Middleware - [ ] Auth (Bearer Token + Localhost-Bypass) - [ ] Rate Limiting (Global + Per-Endpoint) - [ ] Request-ID Tracking - [ ] Structured Logging - [ ] Prometheus Metrics - [ ] CORS ### 5. Migration & Testing - [ ] Parallelbetrieb: Go-Backend neben Node-Backend testen - [ ] API-Kompatibilitätstests gegen OpenAPI-Spec - [ ] Load-Tests: Memory, Connections, Throughput vergleichen - [ ] Hooks, Worker und UI gegen Go-Backend testen ### 6. Deployment - [ ] Single Binary Build - [ ] Docker-Image (multi-stage, ~20MB) - [ ] Systemd-Service-Datei anpassen - [ ] Startup-Logik im Plugin anpassen (Go-Binary statt Node) ## Erwartete Verbesserungen | Metrik | Node (aktuell) | Go (erwartet) | |--------|---------------|---------------| | Memory (Backend) | ~100MB | ~15MB | | Startup | ~2-3s | <100ms | | Binary Size | N/A (Node Runtime) | ~15-20MB | | WS Connections | Hunderte (Event-Loop) | 100k+ (Goroutines) | | Concurrency | Single-Thread | Multi-Core nativ | ## Risiken - Multi-DB-Support (SQLite + PostgreSQL) ist in Go ohne ORM aufwändiger - FTS5-Queries müssen manuell getestet werden (kein ORM-Abstraktionslayer) - Go-Error-Handling ist verbose verglichen mit TypeScript try/catch - Lernkurve für Go-Idiome (channels, goroutines, interfaces) ## Teil von #321 Backend-Migration: Inkrementeller Wechsel von Node/TypeScript zu Go
jack closed this issue 2026-01-26 08:32:46 +00:00
Sign in to join this conversation.
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.

Reference
customable/claude-mem#323
No description provided.