Bun

Bun ist die primäre Runtime, die actor-ts adressiert. Zuerst getestet; Performance-Benchmarks laufen gegen Bun; die Docs nehmen standardmäßig Bun an.

Warum Bun

Grund	Detail
Schneller Start	~3-5× schnellerer Cold-Start vs Node.
Eingebautes SQLite	`bun:sqlite` — keine Peer-Deps.
Eingebauter Test-Runner	`bun:test` — funktioniert für die Tests des Frameworks + deine eigenen.
Natives HTTP / WebSocket	`Bun.serve` für produktionstaugliches HTTP.
Weniger Peer-Deps	Bun ersetzt `ws`, `better-sqlite3` und einige andere.

Installation

curl -fsSL https://bun.sh/install | bash
# oder via Homebrew: brew install oven-sh/bun/bun

Check:

bun --version    # 1.1+ benötigt

Für Docker:

FROM oven/bun:1.1
WORKDIR /app
COPY . .
RUN bun install
CMD ["bun", "run", "dist/main.js"]

Ein Projekt erzeugen

bun init
bun add actor-ts
bun add ts-pattern    # Peer-Dep, die von den Framework-Beispielen genutzt wird

Für spezifische Protokoll-Actor:

bun add kafkajs       # für KafkaActor
bun add mqtt          # für MqttActor
bun add amqplib       # für AmqpActor
bun add nats          # für NatsActor / JetStreamActor
bun add redis         # für RedisStreamsActor
bun add @grpc/grpc-js @grpc/proto-loader   # für GrpcActor

Die meisten Peer-Deps überspringst du, sofern du das spezifische Protokoll nicht nutzt.

Tests laufen lassen

bun test

Bun’s Test-Runner ist drop-in-kompatibel mit Jests API (describe / it / expect). TestKit funktioniert direkt:

import { describe, it, beforeEach, afterEach } from 'bun:test';
import { TestKit } from 'actor-ts/testkit';

describe('Counter', () => {
  let tk: TestKit;
  beforeEach(() => { tk = TestKit.create(); });
  afterEach(async () => { await tk.shutdown(); });

  it('inkrementiert', async () => {
    // ...
  });
});

Für Bun-spezifische Test-Features siehe die Bun-Docs.

SQLite auf Bun

import { SqliteJournal } from 'actor-ts';

// Bun erkennt automatisch bun:sqlite — kein Treiber-Setup nötig.
new SqliteJournal({ path: '/var/lib/events.db' });

bun:sqlite ist eingebaut. Kein better-sqlite3-Install erforderlich.

TCP + HTTP

Bun hat native APIs für beides, aber das Framework wählt sie automatisch via Runtime-Erkennung. Keine Config nötig.

Fürs HTTP-Backend ist die schlankste Option HonoBackend, das auf dem WHATWG-fetch-Adapter aufbaut, den Bun ohnehin anbietet:

import { HonoBackend } from 'actor-ts/http';

await http.newServerAt('0.0.0.0', 8080)
  .useBackend(new HonoBackend())
  .bind(routes);

Hono ist schnell auf Bun und tree-shaket zu einem winzigen Bundle. Für das breitere Node-Ökosystem (Fastify-Plugins, Middleware) bleibe beim Default-Fastify-Backend.

Performance auf Bun

Grobe Zahlen (Single-Bun-Prozess, M-Series-Mac):

Tell-Durchsatz: ~10 M msgs/sec auf MicrotaskDispatcher.
HTTP-Durchsatz: ~150 K req/sec für triviale Routen.
SQLite-Append-Durchsatz: ~50 K Events/sec.

Bun gewinnt konsistent bei Start-Zeit (sub-100 ms vs Nodes ~300-500 ms). Hilfreich für schnelle Test-Iteration.

Bun-spezifische Limitierungen

# Die meisten Node-Pakete funktionieren; ein paar nicht:
# - Native Bindings, die spezifisch gegen Node-ABI linken
# - Manche Streams-API-Edge-Cases

Bun strebt Node-Kompatibilität an, ist aber nicht Bug-kompatibel. Wenn ein Drittanbieter-Paket fehlverhält, prüfe Bun’s Node-Compat-Notes für bekannte Unterschiede.

# AWS Lambda liefert Bun nicht als Runtime aus

Cloud Functions / Lambda Layers verlangen typischerweise Node. Wenn Serverless dein Ziel ist, nutze Node.

Wo es weitergeht

Runtime — Überblick — das größere Bild.
Node — für Node-spezifische Hinweise.
Kompatibilitäts-Matrix — Feature-für-Feature-Unterstützung.
Installation — die Per-Runtime-Install-Schritte.