Zum Inhalt springen
actor-ts
Deutsch

Runtime — Überblick

actor-ts adressiert drei JavaScript-Runtimes:

RuntimeStatusAnmerkungen
BunPrimärDie Runtime, gegen die wir zuerst testen. Natives SQLite, nativer Test-Runner, schnellster Start.
NodeVoll unterstütztBraucht better-sqlite3 als Peer-Dependency für SQLite-Pfade. Manche optionalen Features brauchen Node 22+ für native Pfade.
DenoBest-EffortFunktioniert für die meisten Features; weniger getestet als Bun/Node.

Das Runtime-Erkennungs-Modell des Frameworks wählt beim Startup das richtige Backend für runtime-spezifische Dinge — SQLite-Treiber, TCP-Backends, File-APIs. Du schreibst denselben Code; das Framework adaptiert.

Eine Runtime wählen

Abschnitt betitelt „Eine Runtime wählen“

Für die meisten User:

  • Bun, wenn du kannst. Schneller, leichter, weniger Peer-Dependencies.
  • Node, wenn deine Umgebung es verlangt — die meisten Managed-Plattformen (AWS Lambda Layers, Cloud Functions usw.) sind standardmäßig Node.
  • Deno, wenn du schon darauf gesetzt hast.

Wie Runtime-Erkennung funktioniert

Abschnitt betitelt „Wie Runtime-Erkennung funktioniert“

Das Framework prüft beim Modul-Laden:

if (typeof Bun !== 'undefined') { /* Bun */ }
else if (typeof Deno !== 'undefined') { /* Deno */ }
else if (typeof process !== 'undefined') { /* Node */ }

Spezifische Subsysteme (SQLite, TCP, fs) haben ihre eigenen Adapter-Dateien; jede erkennt + wählt das richtige Backend.

Das heißt kein Runtime-Flag — das Framework funktioniert einfach mit der Runtime, die es startet.

Was sich zwischen Runtimes unterscheidet

Abschnitt betitelt „Was sich zwischen Runtimes unterscheidet“

Für den meisten Code unterscheidet sich nichts:

  • Actor-Lebenszyklus.
  • Cluster-Gossip.
  • Persistenz + Journals.
  • HTTP-Routing + -Serving.
  • Broker (die meisten kümmern sich nicht um die Runtime).

Was sich unterscheidet:

BelangBunNodeDeno
SQLitebun:sqlite (eingebaut)better-sqlite3 (Peer-Dep)Nicht unterstützt
TCPBun.connect / Bun.listennode:netDeno.connect / Deno.listen
WebSocket-ServerBun.serve (eingebaut)ws (Peer-Dep)Deno.serveHttp
HTTP-ServerFastify / Bun.serve / ExpressFastify / ExpressFastify
File-I/OBun.file / node:fsnode:fsDeno.open
Test-Runnerbun:testnode:test / vitest / jestDeno.test

Siehe die Kompatibilitäts-Matrix für die volle Aufschlüsselung.

Cross-Runtime-Cluster

Abschnitt betitelt „Cross-Runtime-Cluster“

Du kannst einen Cluster mit gemischten Runtimes betreiben:

Node-1: Bun
Node-2: Node 20
Node-3: Bun

Cluster-Gossip + -Transport sind wire-format-kompatibel über alle drei. Meistens nützlich für Migration — gradueller Rollout von Node nach Bun zum Beispiel.

In der Praxis: eine Runtime pro Cluster bevorzugen — Mischen macht Debuggen schwerer (andere Stack-Traces, andere Fehlermeldungen, andere Perf-Profile).

Runtime-Upgrades

Abschnitt betitelt „Runtime-Upgrades“
UpgradeAufwand
Bun-Patch-VersionenDrop-in; Pods neu starten.
Bun-Major-VersionenIn Staging testen; sollte drop-in sein, aber wert zu verifizieren.
Node-PatchDrop-in.
Node-Minor (z. B. 22.x → 22.y)Drop-in.
Node-Major (z. B. 20 → 22)Gründlich testen; manche Node-APIs ändern sich.
Bun ↔ Node wechselnVollen Workload testen; Perf-Profil unterscheidet sich.

Für Produktion pinne Runtime-Versionen in deinem Container- Image:

FROM oven/bun:1.1.30    # explizites Tag, kein `latest`

Wann auf jedem deployen

Abschnitt betitelt „Wann auf jedem deployen“

Bun ist empfohlen für:

  • Neue Projekte.
  • Cluster-Nodes, die du kontrollierst.
  • Maximale Perf / minimale Dependencies.

Node ist empfohlen für:

  • Bestehende Node-Shop-Infrastruktur.
  • Plattformen, die Bun noch nicht unterstützen (AWS Lambda, Cloud Functions, manche PaaS).
  • Compliance-Gründe (Node hat eine viel ältere Audit-Historie).

Deno ist empfohlen für:

  • Deno-First-Organisationen.
  • Edge-artige Deployments (Deno Deploy).

Wo es weitergeht

Abschnitt betitelt „Wo es weitergeht“