Claude Code & Hono: Ultra-schnelle Web-APIs für Edge und Node.js

Express hat eine Ära geprägt. Millionen von APIs laufen darauf, unzählige Tutorials beginnen damit — aber Express wurde für eine andere Zeit gebaut. Keine nativen TypeScript-Typen, kein Edge-Support, keine modernen Web-Standards. Wer heute eine neue API aufsetzt, hat bessere Optionen.

Hono ist eine dieser Optionen — und zwar eine, die in jedem relevanten Benchmark vor Express liegt: schnelleres Routing, geringerer Speicherverbrauch, vollständige TypeScript-Integration ab dem ersten Zeichen. Und weil Hono die Web-Standard-APIs (Request, Response, Headers) verwendet, läuft derselbe Code auf Cloudflare Workers, Bun, Node.js, Deno und AWS Lambda — ohne Adapter-Tricks.

Dieser Artikel zeigt, wie Claude Code und Hono zusammenarbeiten: wie Claude Code eine vollständige Hono-API entwirft, testet und auf die Edge deployt — und warum dieses Duo für neue Backend-Projekte kaum zu schlagen ist.

1. Warum Hono schneller ist als Express

Express basiert auf dem Node.js-eigenen http-Modul und hat über die Jahre eine Menge Kompatibilitätsschichten angesammelt. Jeder Request durchläuft einen Middleware-Stack, der sequenziell abgearbeitet wird — unabhängig davon, ob die Middleware für diesen Request überhaupt relevant ist.

Hono verwendet einen Trie-basierten Router (RegExpRouter), der Routen beim Start kompiliert und beim Matching keine regulären Ausdrücke zur Laufzeit auswertet. Das Ergebnis: Routing in O(1) für die meisten Pfade, ohne den Overhead eines vollständigen Middleware-Durchlaufs für jede Anfrage.

• Express: ~35.000 Requests/Sekunde (einfache JSON-Route, Node.js 22)
• Hono auf Node.js: ~110.000 Requests/Sekunde, gleiche Route
• Hono auf Bun: ~220.000 Requests/Sekunde
• Hono auf Cloudflare Workers: nahezu unbegrenzt skalierend, 0 ms Cold Start

Zahlen variieren je nach Hardware und Testszenario — aber die Größenordnung stimmt. Hono ist nicht marginal schneller. Es ist eine andere Klasse.

2. Hono in 5 Minuten mit Claude Code aufsetzen

Claude Code liest die offizielle Hono-Dokumentation kennt die gängigen Patterns und generiert produktionsreife Projekte — nicht nur Copy-Paste-Snippets. Ein Prompt, der funktioniert:

claude "Erstelle eine neue Hono-API für Node.js mit:
- TypeScript, strict mode
- GET /health (gibt {status:'ok',ts:Date.now()} zurück)
- POST /items (Body: {name:string,price:number}, validiert mit zod)
- Bearer-Token-Auth als Middleware (Token aus process.env.API_TOKEN)
- Fehler-Handler der {error,message} zurückgibt
- package.json mit tsx für lokale Entwicklung"

Was Claude Code daraus macht, ist ein vollständiges Projekt mit korrekter Ordnerstruktur, Zod-Validation, einem sauber getrennten Middleware-Layer und einem src/index.ts, das direkt läuft. Keine Platzhalter, keine // TODO-Kommentare.

Das Ergebnis: eine produktionsreife Hono-API

import { Hono } from 'hono'
import { zValidator } from '@hono/zod-validator'
import { z } from 'zod'

const app = new Hono()

// Auth-Middleware
app.use('/items/*', async (c, next) => {
  const token = c.req.header('Authorization')?.replace('Bearer ', '')
  if (token !== process.env.API_TOKEN) {
    return c.json({ error: 'Unauthorized' }, 401)
  }
  await next()
})

// Health-Route
app.get('/health', (c) => c.json({ status: 'ok', ts: Date.now() }))

// Items-Route mit Zod-Validation
const itemSchema = z.object({
  name: z.string().min(1),
  price: z.number().positive(),
})

app.post('/items', zValidator('json', itemSchema), async (c) => {
  const data = c.req.valid('json')
  // Datenbanklogik hier...
  return c.json({ id: crypto.randomUUID(), ...data }, 201)
})

// Fehler-Handler
app.onError((err, c) => {
  return c.json({ error: err.name, message: err.message }, 500)
})

export default app

Beachte: process.env.API_TOKEN wird nie im Code hartcodiert — die Middleware liest den Token aus der Umgebung. Claude Code macht das standardmäßig richtig, wenn der Prompt es klar benennt.

3. Cloudflare Workers, Bun und Node.js — ein Code, drei Runtimes

Das Besondere an Hono ist, dass dieselbe App auf mehreren Runtimes läuft. Der Adapter entscheidet, wie die App gestartet wird — der eigentliche Code bleibt identisch.

// Cloudflare Workers (wrangler.toml + export default app)
export default app

// Node.js (mit @hono/node-server)
import { serve } from '@hono/node-server'
serve({ fetch: app.fetch, port: 3000 })

// Bun (direkt, kein Adapter nötig)
export default { port: 3000, fetch: app.fetch }

Claude Code kennt alle drei Adapter und wählt den richtigen automatisch, wenn du die Zielplattform nennst. Für Cloudflare Workers generiert es zusätzlich eine passende wrangler.toml mit korrekten Kompatibilitätsdaten:

claude "Konfiguriere die Hono-App für Cloudflare Workers mit wrangler.toml,
D1-Datenbank-Binding und Secrets für API_TOKEN"

4. JSX-Rendering: Hono als Full-Stack-Framework

Hono kann nicht nur JSON — es hat ein eigenes JSX-Rendering eingebaut, ohne React als Abhängigkeit. Das ist ideal für serverseitig gerenderte Seiten, die direkt auf der Edge laufen sollen.

/** @jsx jsx */
import { jsx } from 'hono/jsx'

app.get('/page', (c) => {
  return c.html(
    <html>
      <body>
        <h1>Hallo von der Edge</h1>
        <p>Dieser HTML wurde auf Cloudflare Workers generiert.</p>
      </body>
    </html>
  )
})

Claude Code schreibt Hono-JSX-Komponenten korrekt — inklusive des @jsx jsx-Pragmas, das in vielen Tutorials vergessen wird und zu kryptischen Compile-Fehlern führt.

5. Der RPC-Client: Typsicherheit vom Server bis zum Browser

Eine der stärksten Funktionen von Hono ist der RPC-Client: ein typsicherer Client, der automatisch aus den Routen-Definitionen generiert wird. Kein separates API-Schema, kein manuelles Tippen von Fetch-Calls.

// server.ts
const routes = app
  .get('/users/:id', async (c) => {
    const id = c.req.param('id')
    return c.json({ id, name: 'Alice' })
  })

export type AppType = typeof routes

// client.ts (im Frontend oder in Tests)
import { hc } from 'hono/client'
import type { AppType } from './server'

const client = hc<AppType>('http://localhost:3000')

// Vollständige TypeScript-Autovervollständigung:
const user = await client.users[':id'].$get({ param: { id: '42' } })
const data = await user.json() // Typ: { id: string, name: string }

Claude Code versteht das RPC-Pattern und generiert Server- und Client-Code gemeinsam, wenn du es bittest: "Erstelle eine Hono-Route und den passenden RPC-Client-Aufruf dafür." Das spart das manuelle Synchronisieren von Server- und Client-Typen, das bei REST-APIs sonst fehlerträchtig ist.

6. Testing mit dem Hono Test Client

Hono bringt einen eingebauten Test-Client mit, der keine laufende HTTP-Instanz braucht. Das macht Tests schnell und unabhängig von Netzwerk oder Port-Belegung.

import { testClient } from 'hono/testing'
import { describe, it, expect } from 'vitest'
import app from './index'

describe('GET /health', () => {
  it('gibt status ok zurück', async () => {
    const client = testClient(app)
    const res = await client.health.$get()
    expect(res.status).toBe(200)
    const body = await res.json()
    expect(body.status).toBe('ok')
    expect(typeof body.ts).toBe('number')
  })
})

describe('POST /items', () => {
  it('lehnt ungültige Daten ab', async () => {
    const client = testClient(app)
    const res = await client.items.$post({
      json: { name: '', price: -5 }
    })
    expect(res.status).toBe(400)
  })
})

Claude Code schreibt diese Tests automatisch mit, wenn du beim Erstellen der Route nach Tests fragst. Die Kombination aus Zod-Validation und Hono-Testclient deckt Randfall-Szenarien ab, die in manuell geschriebenen Tests oft vergessen werden.

7. Claude Code-Tipps für Hono-Projekte

Aus dem produktiven Einsatz: Was funktioniert gut, was nicht?

• Immer die Zielplattform nennen: "Hono für Cloudflare Workers" statt nur "Hono-API" — Claude Code wählt dann den richtigen Adapter, die richtige Konfiguration und die richtigen Imports.
• Middleware als separate Datei: Bitte Claude Code, Auth, Logging und Rate-Limiting in eigene Dateien zu legen. Das macht spätere Anpassungen einfacher und die Tests klarer.
• RPC-Typen von Anfang an: Wenn du weißt, dass du einen Frontend-Client brauchst, sag das beim ersten Prompt. Claude Code baut das RPC-Pattern dann von Anfang an ein — nachträglich einbauen ist mühsamer.
• Fehlertypen explizit definieren: Frage nach einem zentralen Error-Handler mit unterschiedlichen HTTP-Status-Codes für Validation-, Auth- und Server-Fehler. Hono macht das einfach, aber nur wenn du es explizit anforderst.
• D1, KV und R2 benennen: Wenn deine Cloudflare-App D1, KV oder R2 nutzt, nenn das im Prompt. Claude Code generiert dann die korrekten Binding-Typen und Environment-Interfaces, die Cloudflare Workers erwartet.

"Hono ist das erste Backend-Framework, das ich empfehle — nicht weil es hip ist, sondern weil es richtig gebaut ist: Web-Standards, TypeScript-first, null unnötige Abhängigkeiten. Und weil Claude Code Hono sehr gut kennt, geht der Einstieg ungewöhnlich reibungslos."

Fazit

Hono löst ein echtes Problem: Backend-Code, der auf jeder modernen Runtime läuft, ohne Klimmzüge. Cloudflare Workers, Bun, Node.js, Deno — ein Framework, ein Codebasis. Die Performance-Zahlen sprechen für sich, aber der eigentliche Vorteil ist die Entwicklererfahrung: vollständige TypeScript-Typen, eingebauter Test-Client, RPC ohne Schema-Duplizierung.

Claude Code beschleunigt den Einstieg erheblich, weil es nicht nur Snippets generiert, sondern vollständige, produktionsreife Projekte mit korrekter Konfiguration, Fehlerbehandlung und Tests. Wer Hono heute noch nicht kennt und mit Claude Code arbeitet, hat einen guten Startpunkt: einfach fragen.

• Claude Code Debugging — wie Claude Code Bugs systematisch findet und behebt
• Claude Code für Unternehmen — Deployment, Zugriffskontrolle und Team-Workflows