SpacetimeDB var et godt eksperiment, men gir synk-kompleksitet, dobbelt vedlikehold og en ekstra SPOF for minimal latensgevinst på denne skalaen. PG LISTEN/NOTIFY + WebSocket i portvokteren erstatter sanntidslaget. - datalaget.md: revidert med ny lagmodell, PG-triggers, migrasjonsplan - retninger/README.md: oppdatert status til «Revidert» - tasks.md: ny fase 22 (STDB-migrering) med 5 oppgaver (M1–M5) - 12.4 oppdatert fra «profiler STDB» til «profiler PG» Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
5.3 KiB
Datalaget
Status: Besluttet. Revidert mars 2026 — SpacetimeDB fases ut.
PostgreSQL er eneste datakilde. Sanntid via PG
LISTEN/NOTIFYog WebSocket i portvokteren. CAS lagrer binærdata. Apache AGE legges til ved behov for Cypher-traverseringer. SpacetimeDB fases ut — se migrasjonsplan.
Lagmodell
GUI (SvelteKit)
│ skriv │ les (sanntid, WebSocket)
▼ ▼
Portvokteren (Rust) Portvokteren ──WebSocket──→ GUI
│ validering ▲
└──→ PostgreSQL ──NOTIFY──→──┘
Skrivestien
GUI → portvokteren → validering → PG. Frontend oppdateres via WebSocket-push utløst av PG NOTIFY.
Lesestien (sanntid)
PG → portvokteren → WebSocket → GUI. Portvokteren holder en in-memory cache av aktive subscriptions og pusher relevante endringer til tilkoblede klienter.
Lesestien (tunge spørringer)
GUI → portvokteren → PG. Fulltekstsøk, pgvector, statistikk, AGE-traverseringer.
PostgreSQL — eneste datakilde
Én sannhetskilde. Ingen synk, ingen konsistensproblemer:
- Sanntid:
LISTEN/NOTIFY→ portvokteren → WebSocket - Fulltekstsøk:
tsvectorpånodes.contentognodes.title - Semantisk søk: pgvector for embedding-basert likhet
- Graftraversering: rekursive CTEs, Apache AGE ved behov
- Statistikk: aggregeringer, tidsserier
- Tilgangsmatrise:
node_accessberegnet fra edges
Apache AGE — ved behov
De fleste spørringer er grunne (1-3 hopp) og håndteres av CTEs. AGE legges til som PG-extension når Cypher-semantikk faktisk trengs:
- Nå: PG med nodes/edges-tabeller og CTEs
- Når CTEs blir smertefulle: Legg til AGE
- Usannsynlig: Evaluer Neo4j hvis AGE ikke holder
AGE er en extension, ikke en migrering.
CAS — binærlagring
Lyd, bilde, video lagres content-addressable på disk. CAS-noder
i grafen bærer metadata (cas_hash, mime, size_bytes).
Selve biten lever utenfor PG.
Pruning-regler basert på modalitet, edges og aksessmønstre. Se maskinrommet.
Sanntid via PG LISTEN/NOTIFY
PG har innebygd pub/sub. Portvokteren lytter og videresender:
PG: NOTIFY node_changed, '{"id":"abc","kind":"content"}'
→ Portvokteren mottar
→ Sjekker tilgangsmatrise: hvem skal se denne endringen?
→ Pusher til relevante WebSocket-tilkoblinger
→ Frontend oppdaterer reaktivt
Trigger i PG
CREATE OR REPLACE FUNCTION notify_node_change()
RETURNS trigger AS $$
BEGIN
PERFORM pg_notify('node_changed',
json_build_object(
'op', TG_OP,
'id', NEW.id,
'kind', NEW.node_kind
)::text
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER nodes_notify
AFTER INSERT OR UPDATE ON nodes
FOR EACH ROW EXECUTE FUNCTION notify_node_change();
Tilsvarende for edges.
WebSocket i portvokteren
Portvokteren holder:
- Map av tilkoblede klienter → brukerens node_id
- Map av node_id → synlige noder (fra node_access)
- Ved NOTIFY: filtrer på tilgang, push til relevante klienter
Enklere enn STDB-synk: én retning (PG → klient), ingen reducer-logikk, ingen konsistensproblemer.
Hvorfor SpacetimeDB fases ut
SpacetimeDB var et godt eksperiment. Det løste sanntid elegant i prototype-fasen. Men for produksjon på én server:
- Synk-kompleksitet. PG ↔ STDB synk er en egen feilkategori. Erfaringsdocs (adapter_moenster.md, spacetimedb_integrasjon.md) dokumenterer smerten.
- Dobbelt vedlikehold. STDB-modul med reducers må holdes i synk med PG-skjema. Endring i nodes-tabellen → to steder.
- Ekstra SPOF. Enda en tjeneste å overvåke, restarte, debugge.
- Unødvendig for skalaen. PG LISTEN/NOTIFY + WebSocket gir ~5ms latency. STDB ga ~0.01ms. Forskjellen er umerkelig for brukere.
- CLI-verktøy forenkles. Bare PG-tilkobling, ingen STDB-klient.
Migrasjonsplan: STDB → PG LISTEN/NOTIFY
Fase M1: WebSocket-lag i portvokteren
Implementer LISTEN/NOTIFY-lytter og WebSocket-endepunkt i portvokteren. Legg til PG-triggers for nodes og edges. Frontend kobler til begge (STDB + nytt WS) i parallell.
Fase M2: Frontend-migrering
Endre frontend fra SpacetimeDB-klient til vanlig WebSocket. Erstatt STDB-stores med reaktive stores som lytter på portvokterens WebSocket. Verifiser at all sanntidsfunksjonalitet fungerer.
Fase M3: Fjern skrivestien til STDB
Portvokteren slutter å skrive til SpacetimeDB. All skriving går kun til PG. NOTIFY-triggere er eneste push-mekanisme.
Fase M4: Fjern STDB
- Stopp SpacetimeDB Docker-container
- Fjern STDB-modul (spacetimedb/)
- Fjern STDB-klient fra portvokteren
- Fjern STDB-avhengigheter fra frontend
- Fjern synkroniserings-kode
- Oppdater docs (synkronisering.md → arkiver)
- Oppdater CLAUDE.md
Fase M5: Opprydding
- Slett erfaringsdocs som kun gjelder STDB
- Oppdater alle docs-referanser til STDB
- Fjern Docker-konfig for SpacetimeDB
Forhold til andre retninger
- Noder er sentrum — tilgangsmatrise beregnet fra edge-grafen, brukes for WebSocket-filtrering
- Universell input og mottak — noder og edges er datamodellen for alle tre primitiver
- Maskinrommet / Portvokteren — CAS-pruning, edge-drevet ressursorkestrering, validering før skriving, WebSocket-endepunkt for sanntid