Zum Inhalt springen
actor-ts
Deutsch

Hono-Backend

Hono ist ein runtime-agnostisches HTTP- Framework — derselbe Code läuft auf Bun, Node, Deno, Cloudflare Workers, AWS Lambda, Vercel usw. HonoBackend wickelt es für actor-ts ein.

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


const http = system.extension(HttpExtensionId);


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

Wann Hono

Abschnitt betitelt „Wann Hono“

Hono ist die richtige Wahl, wenn:

  • Edge / Serverless — Cloudflare Workers, Vercel Edge, Deno Deploy. Hono ist eines der wenigen HTTP-Frameworks, die in solchen Umgebungen laufen.
  • Cross-Runtime-Portabilität — derselbe Code auf Bun + Node
    • Edge.
  • Minimaler Overhead — Hono ist leichter als Fastify, schneller als Express.

Für einen typischen, langlebigen Produktionsserver ist Fastify meist vorzuziehen — größeres Plugin-Ökosystem, mehr Produktionsstunden. Hono glänzt, wenn “läuft an vielen Orten” harte Anforderung ist.

Cross-Runtime- + Serverless-Vorbehalt

Abschnitt betitelt „Cross-Runtime- + Serverless-Vorbehalt“
// Auf einer langlebigen VM: das funktioniert
await http.newServerAt('0.0.0.0', 8080)
  .useBackend(new HonoBackend())
  .bind(routes);


// Auf Cloudflare Workers: es gibt kein "newServerAt(host, port)"
//   Die Runtime ruft pro Request einen Handler auf.

HonoBackend exponiert seine zugrunde liegende Hono-Instanz:

const backend = new HonoBackend();
const honoApp = backend.app;   // ← in die Edge-Runtime exportieren

In Cloudflare Workers:

worker.ts
export default { fetch: honoApp.fetch };

Die actor-ts-Seite läuft dann In-Memory innerhalb des Isolates — kurzlebig, kein Clustering, keine Persistenz. Nützlich für zustandslose Request-Handling-Logik, die von Actor-Mustern profitiert (Zustandsautomaten, Validierungs-Pipelines).

Für langlebige Actor-Systeme mit Cluster + Persistenz läuft nicht auf Edge-Runtimes — die sind Isolate-pro-Request, keine langlebigen Prozesse.

Konfiguration

Abschnitt betitelt „Konfiguration“
new HonoBackend({
  // Hono selbst hat minimale Konfiguration; die meisten Einstellungen kommen über Routen / Middleware
});

Hono-Middleware

Abschnitt betitelt „Hono-Middleware“
import { logger, cors, secureHeaders } from 'hono/middleware';


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


backend.app.use('*', logger());
backend.app.use('/api/*', cors());
backend.app.use('*', secureHeaders());

Honos Middleware-Ökosystem ist kleiner als das von Express, deckt aber die üblichen Fälle ab — CORS, Security-Header, JWT-Auth, Basic-Auth, Komprimierung.

Peer-Dependency

Abschnitt betitelt „Peer-Dependency“
Terminal-Fenster
npm install hono
# oder: bun add hono

Performance

Abschnitt betitelt „Performance“

Grobe Zahlen:

  • 100K–150K req/sec auf Bun für triviale Routen.
  • Etwas langsamer als Fastify auf Node.
  • Edge-Runtime-Zahlen hängen von der Plattform ab (Cloudflare Workers: ~50K req/sec pro Worker; von der Plattform gedrosselt).

Edge-Runtime-Vorbehalte

Abschnitt betitelt „Edge-Runtime-Vorbehalte“

Wohin als Nächstes

Abschnitt betitelt „Wohin als Nächstes“