Bun.js Middleware 2026: was sie ist, wie sie funktioniert, wie man sie optimiert und wo man die API nicht kaputtmacht
Ein praktischer Guide zu Middleware in Bun.js: native Bun.serve, Hono, Elysia, Auth, CORS, Rate Limiting, Logging, Observability, Performance, Best Practices und schlechte Praktiken. Wir erklären, wann Middleware hilft, wann sie Latenz erzeugt und wie man production-ready APIs auf Bun baut.
Bun.js Middleware Production Guide 2026
Eine Serie über Production Middleware in Bun.js: Überblick, Security, Performance, Observability, Rate Limiting, Body Parsing, WebSocket/SSE und Tests für die Request Pipeline.
Alle Artikel in diesem Guide
01
Bun.js Middleware 2026: Overview, Best Practices und Anti-Patterns
Das grundlegende mentale Modell für Middleware in nativem Bun, Hono und Elysia, mit Beispielen, Optimierung und Roadmap für die nächsten Deep-Dive-Artikel.
02
Auth Middleware in Bun.js: JWT, Sessions, API Keys und Multi-Tenant Context
Wie man Auth Middleware in Bun richtig baut: Reihenfolge der Prüfungen, Cache, Token Rotation, Tenant Context, 401/403-Fehler und Tests.
03
Rate Limiting in Bun.js: in-memory, Redis, Sliding Window und Edge Cases
Ein detaillierter Blick auf Rate Limiting für Bun APIs: Algorithmen, Redis, distributed limits, abuse protection und graceful degradation.
04
Observability Middleware in Bun.js: Logs, Request ID, Tracing und Latency Budgets
Wie man request id, structured logs, timing headers, einen OpenTelemetry-ähnlichen Flow hinzufügt und Logging nicht zum Bottleneck macht.
05
Body Parsing und Validation in Bun.js: JSON, Uploads, Streams und Payload Limits
Wie man Request Bodies in Bun sicher liest, wo Limits hingehören und wie man Streams, Uploads, Idempotency und Schema Validation nicht kaputtmacht.
Bun kann HTTP-Requests schnell annehmen, aber es kann keine Pipeline magisch reparieren, in der jede Middleware den Body liest, unnötige Objekte erzeugt, synchrones Crypto ausführt, verbose Logs schreibt und für jeden public endpoint den User aus der Datenbank holt.
Deshalb ist gute Bun Middleware nicht einfach „noch ein .use() hinzufügen“. Es ist Design der Request Pipeline: was vor dem Routing geprüft wird, was nach dem Routing läuft, was short-circuit machen kann, was Zugriff auf den Body hat, was gecacht wird, was gemessen wird und was überhaupt keine Middleware sein sollte.
Wenn du 2026 eine Bun API planst, hilft dir dieser Artikel, Node/Express-Gewohnheiten nicht dort zu wiederholen, wo Bun ein anderes Modell und bessere Primitives bietet.
Bun.serve ohne Express-Illusionen.kurze karte
Das ist kein „Hello World“-Tutorial. Es ist ein praktischer Überblick für Teams, die Bun APIs mit sauberer Request Pipeline bauen wollen, statt Express-Middleware-Chaos in einen anderen Runtime zu verschieben.
Im klassischen Express-Denken ist Middleware eine Funktion zwischen Request und Response, die req verändern, res verändern, next() aufrufen oder die Response beenden kann. In nativem Bun ist das Modell anders: Der Basiserver arbeitet mit den Web APIs Request und Response, und Bun.serve akzeptiert einen fetch handler oder routes. „Middleware“ in nativem Bun ist also kein eingebauter Express-like Mechanismus, sondern ein Architekturpattern für Funktionskomposition rund um einen Handler. [1][2]
Das ist ein wichtiger Unterschied. Wenn du natives Bun schreibst, entscheidest du selbst, wie die Pipeline aussieht: Array von Funktionen, Wrapper um einen Handler, kleiner Router oder vollständiges Framework. Bun gibt dir einen schnellen HTTP Server, routes, static responses, file responses, timeouts, request IP und WebSocket controls. Aber es zwingt dir kein Middleware-Modell auf. [2][3]
Hono und Elysia füllen diese Schicht unterschiedlich. Hono nennt Middleware eine „onion structure“: Middleware läuft vor dem Handler, kann await next() ausführen und danach die Response nach dem Handler ändern. Elysia beschreibt Lifecycle Events: request, parse, transform, beforeHandle, afterHandle, mapResponse, error, afterResponse und trace. [5][6]
Kurz gesagt
Bun Middleware ist nicht ein einzelnes API. Es gibt drei praktische Modi: native Komposition rund um Bun.serve, Hono .use() für Web Standards Middleware oder Elysia Lifecycle Hooks für einen Bun-first Framework-Ansatz.
Wichtig ist, Middleware nicht vom Runtime-Kontext zu trennen. Bun optimiert HTTP Server und Routes, Hono optimiert ein einfaches Middleware-Modell, Elysia optimiert einen typed lifecycle. Das sind unterschiedliche Antworten auf dieselbe Aufgabe.
Bun positioniertBun.serveals high-performance HTTP server, und die routes API unterstützt static responses, dynamic routes, method handlers und fallbackfetch. [1][2]
Bun.serveHono beschreibt Middleware direkt als Code, der before/after handler läuft,await next()ausführen oder eineResponsefür early-exit zurückgeben kann. [5]
Elysia zerlegt den request-response cycle in lifecycle events, bei denen Hooks in Registrierungsreihenfolge auf Routes angewendet werden. [6]
Kurz gesagt
Praktischer Schluss: Suche nicht nach „dem einen richtigen Bun Middleware API“. Wähle zuerst das Lifecycle-Modell, das zu deinem Produkt passt.
Wenn die API klein ist, Latenz wichtig ist und das Team volle Kontrolle möchte, kann eine native Bun Pipeline ausreichen. Die Idee ist simpel: Ein Handler nimmt Request, gibt Response zurück, und Middleware wrappt den Handler oder läuft sequenziell davor.
Das kleinste nützliche Pattern sieht so aus:
type Handler = (req: Request) => Response | Promise<Response>;
type Middleware = (next: Handler) => Handler;
const withRequestId: Middleware = (next) => async (req) => {
const requestId = crypto.randomUUID();
const res = await next(req);
res.headers.set("x-request-id", requestId);
return res;
};
const withSecurityHeaders: Middleware = (next) => async (req) => {
const res = await next(req);
res.headers.set("x-content-type-options", "nosniff");
res.headers.set("referrer-policy", "strict-origin-when-cross-origin");
return res;
};
const compose = (handler: Handler, middleware: Middleware[]) =>
middleware.reduceRight((next, layer) => layer(next), handler);
const app = compose(
async (req) => {
const url = new URL(req.url);
if (url.pathname === "/health") return new Response("OK");
return Response.json({ ok: true });
},
[withRequestId, withSecurityHeaders],
);
Bun.serve({ fetch: app });Dieser Ansatz ist leichtgewichtig, aber er legt Verantwortung auf dich: Reihenfolge, Fehler, Context, wiederholtes Body-Lesen, Route Matching, Typisierung und Tests definierst du selbst.
Das Basismodell einer Middleware Pipeline: günstige Checks sollten den Request vor teurem Handler oder Body Parsing ablehnen.
Screenshot des Abschnitts native-bun-patternWann das sinnvoll ist
Native Komposition eignet sich für kleine APIs, interne Services, Health-/Readiness-Endpoints, Custom Gateways und performance-sensitive Routes. Für große Produkt-APIs sollte man schnell Hono oder Elysia evaluieren.
2026 ist die Frage nicht „gibt es Middleware in Bun?“. Die Frage ist, welches Abstraktionslevel du brauchst und wie viel Lifecycle-Verhalten du selbst pflegen willst.
| Ansatz | Wann wählen | Stärke | Risiko |
|---|---|---|---|
Native Bun.serve | Kleine Services, Gateways, Webhooks, Health Endpoints, Custom Routing | Minimaler Overhead, volle Kontrolle über Web Request/Response | Routing, Context, Errors und Middleware Order schreibst du selbst |
| Hono | APIs, die familiar middleware, Web Standards und Portability brauchen | Einfaches Onion-Model, .use(), built-in und third-party middleware [5] | Express-Gewohnheiten lassen sich leicht übertragen und führen zu zu vielen globalen .use() Layern |
| Elysia | Bun-first APIs, typed context, validation, plugins, lifecycle hooks | Klarer Request Lifecycle und Typisierung in einem Bun-orientierten Framework [6][7] | Registrierungsreihenfolge von Hooks ist kritisch, Lifecycle muss tiefer verstanden werden |
| Express-compatible stack | Migration einer bestehenden Node App, bei der Middleware Ecosystem wichtiger ist als Runtime Purity | Niedrigere Migrationskosten | Ein Teil der Middleware kann sich auf Node/Express-Details verlassen, die getestet werden müssen |
Drei praktische Middleware-Modelle für Bun APIs: native Kontrolle, Hono Onion Middleware oder Elysia Lifecycle Hooks.
Screenshot des Abschnitts framework-choiceKurz gesagt
Wenn du eine neue Bun API startest, ziehe nicht automatisch das Express-Modell mit. Native Bun, Hono und Elysia bieten unterschiedliche Kompromisse zwischen Kontrolle, DX, Typisierung und ecosystem-ready Middleware.
Gute Middleware löst ein Cross-Cutting Concern. Schlechte Middleware versteckt Business Logic in einer globalen Pipeline, in der später niemand mehr versteht, warum sich eine Route genau so verhält.
Authentication und Authorization
Prüfung von JWT/session/API key, Normalisierung von user/tenant context, frühes 401 oder 403. Business-level permissions sollten aber näher am Use Case bleiben und nicht komplett in globaler Middleware versteckt werden.
CORS und Security Headers
Ein guter Kandidat für Middleware, weil Regeln auf viele Routes angewendet werden. Wichtig ist, kein permissives * überall zu setzen, wenn die API mit Credentials oder privaten Daten arbeitet.
Rate Limiting und Abuse Protection
Middleware kann zusätzliche Requests schnell vor Body Parsing und Database Calls abweisen. Für distributed APIs reicht ein lokales Memory Limit nicht, es braucht shared storage oder edge-level policy.
Observability
Request id, structured logs, duration, trace context, error mapping. Das ist eine der nützlichsten Middleware-Schichten, solange sie keine übermäßigen Payloads schreibt und den Response Path nicht blockiert.
Body Parsing und Validation Gate
Payload size limits, content-type checks, JSON parsing, schema validation. Wichtig: Der Body Stream darf nicht blind mehrfach in verschiedenen Schichten gelesen werden.
Response Normalization
Einheitliches Fehlerformat, cache headers, timing headers, compression decisions. Response Middleware sollte aber nicht zum versteckten Serializer für die gesamte Business Logic werden.
Die Geschwindigkeit von Bun bedeutet nicht, dass jede Middleware automatisch billig ist. Pipeline-Optimierung beginnt mit Ausführungsregeln, nicht mit Microbenchmarks.
Günstige Rejects vor teure Operationen stellen
Method, path, content-type, origin, basic headers und IP allowlist sollten vor body parsing, database calls, crypto und remote config laufen. Das reduziert CPU, memory pressure und tail latency.
Body nicht ohne Grund in globaler Middleware lesen
Im Web API Modell ist der Body ein Stream. Wenn Middleware await req.json() liest, kann der Handler ihn nicht mehr genauso einfach lesen. Mach Body Parsing in einer engen Schicht oder gib den parsed body explizit in den Context.
Static Responses für stabile Routes nutzen
Bun Routes können fertige Response Objects akzeptieren. Die offizielle Dokumentation sagt, dass static route responses für die Lifetime des Server Object gecacht werden und Performance Benefit für Health Checks, Redirects und feste API Responses geben können. [2]
Middleware für public und private Routes trennen
Zwinge /health, /ready, /assets/* oder public GET Routes nicht durch auth, session lookup und tenant hydration. In Bun Routes ermöglichen wildcard und specific routes, diese Flächen explizit zu trennen. [2]
Latency Budget für jede Schicht haben
Logging, auth, rate limit, validation, DB context, response mapping — jede Schicht braucht ein Budget. Wenn Middleware 5–10ms auf jeden Request addiert, ist das eine Architekturentscheidung und kein Detail.
Praktische Regel
Eine optimale Bun Middleware Pipeline ist kurz, vorhersehbar und messbar. Alles, was nicht global sein muss, sollte nicht global sein.
Nicht alle Optimierungen sind gleich nützlich. Manche senken Latenz, andere verschieben Komplexität nur an eine Stelle, die schwerer zu debuggen ist.
Gut: static response für health/readiness
Für /health, /ready, einfache Redirects und feste Config Responses nutze route-level static responses. Das reduziert Runtime Work und unnötige Allokationen. [2]
Vorsicht: globale Auth Middleware
Auth als globale Schicht ist bequem, landet aber leicht auf Routes, die sie nicht brauchen. Besser private APIs explizit gruppieren und public/system routes außerhalb dieser Pipeline lassen.
Gut: request id und timing
Das ist eine günstige und nützliche Baseline für Production Debugging. Wichtig ist nur, keine vollständigen Bodies und Secrets zu loggen.
Vorsicht: Body Parsing vor Routing
Wenn Middleware den Body für jeden Request liest, zahlst du den Preis auch dort, wo der Body nicht gebraucht wird. Das schmerzt besonders bei Uploads, Webhooks und Streaming Routes.
Kurz gesagt
Die beste Middleware-Optimierung ist, Middleware dort nicht auszuführen, wo sie nicht gebraucht wird.
Bun hat ein wichtiges Default-Verhalten: HTTP idleTimeout beträgt 10 Sekunden, wenn nichts anderes konfiguriert ist. Für Streaming Responses oder Server-Sent Events empfiehlt die Dokumentation, per-request timeout über server.timeout(req, 0) zu setzen, statt den globalen Timeout für alle Requests zu erhöhen. [3]
Das wirkt direkt auf Middleware. Wenn Logging- oder Auth-Middleware eine Streaming Response so wrappt, als wäre sie ein normaler JSON Endpoint, kannst du versehentlich die Response buffern, den Stream schließen oder die Timeout Policy für alle Routes gleich machen.
Für WebSockets hat Bun eigene Controls: idleTimeout, maxPayloadLength, Backpressure über das Ergebnis von .send(), perMessageDeflate. Auch das Middleware-Denken ist hier anders: Connection Upgrade und Message Lifecycle sollten nicht mit HTTP JSON Middleware vermischt werden. [4]
Regel für lange Connections
SSE, Streams und WebSockets sollten eine eigene Pipeline haben. Schicke sie nicht durch Middleware, die einen kurzen Request-Response JSON Flow annimmt.
Diese Fehler sind aus der Node/Express-Welt bekannt. In Bun werden sie nicht weniger schädlich, sie werden nur durch einen schnelleren Runtime kaschiert.
Globale Middleware für alles: auth, body parsing, logging, rate limit, tenant lookup und validation laufen sogar für /health.
Mehrfaches Lesen des Body in mehreren Schichten ohne klaren Contract, wer Owner des parsed payload ist.
Request-specific Daten in module-level Variablen speichern. In einem concurrent server führt das direkt zu Leakage zwischen Requests.
Teure synchrone Operationen in Middleware: crypto, filesystem, compression, große JSON transforms.
Vollständigen request body, cookies, authorization headers oder PII loggen.
CORS * für private APIs mit credentials.
Nur in-memory rate limiting in multi-instance production.
Kein einheitliches Fehlerformat: eine Middleware gibt Text zurück, eine andere JSON, eine dritte wirft eine Exception.
Middleware verändert die Response so, dass der Handler den Contract nicht mehr garantieren kann.
Der Kern
Middleware sollte cross-cutting behavior explizit machen. Wenn sie Business Rules oder State versteckt, wird die Pipeline komplexer als der Application Code.
Diese Liste kann als Review Checklist vor dem Launch einer Bun API in Staging oder Production genutzt werden.
Separate Pipelines für public, private, system und streaming routes
Zwinge verschiedene Traffic-Typen nicht durch denselben Middleware Stack.
So früh wie möglich short-circuit machen
Method/path/content-type/origin/rate limit sollten schlechte Requests vor teuren Operationen abweisen.
Ein Owner für Body Parsing
Definiere, wer den Body liest, wo der parsed value gespeichert wird und wie der Handler ihn bekommt.
Einheitliches Fehlerformat
Auth, validation, rate limit und internal errors sollten einen vorhersehbaren JSON Contract zurückgeben.
Request ID überall
Füge request id zu response headers und structured logs hinzu, um cross-service flows zu debuggen.
Latency Budget für jede Middleware
Messe duration der Middleware-Schichten, nicht nur die gesamte response time.
Keine Secrets in Logs
Authorization, cookies, API keys, tokens und PII sollten maskiert oder gar nicht geloggt werden.
Tests für Ausführungsreihenfolge
Teste nicht nur happy path, sondern auch early exit, error path, missing headers, invalid body, timeout und streaming routes.
Dieser Post ist der Overview. Danach ist es logisch, jede Middleware-Klasse separat zu betrachten, weil Auth, Rate Limiting, Observability und Body Parsing unterschiedliche Failure Modes haben.
Chapter 2
Auth Middleware
JWT, Sessions, API Keys, Tenant Context, Cache, Token Refresh, 401 versus 403 und wie man Permissions nicht in einer globalen Schicht versteckt.
Chapter 3
Rate Limiting
Fixed window, sliding window, token bucket, Redis, distributed deployment, abusive clients, Webhooks und graceful degradation.
Chapter 4
Observability
Request id, structured logs, timing headers, tracing, error correlation und wie Logging nicht zum Latency Bottleneck wird.
Chapter 5
Body Parsing und Validation
JSON, multipart, uploads, streams, payload limits, schema validation, idempotency keys und sichere Wiederverwendung von parsed body.
Kurz gesagt
Die Serie ist als Production Checklist für Bun APIs nützlich, in denen Middleware kein dekorativer Layer sein soll, sondern ein kontrollierter Teil der Architektur.
Bun gibt dir einen starken HTTP Runtime, schnelle Routes, static responses, Web APIs und niedrigen Overhead. Aber Middleware ist die Stelle, an der Teams am häufigsten die ganze Komplexität des alten Node Stacks zurückholen: globale Side Effects, Body Parsing an der falschen Stelle, Logging ohne Budget, Auth ohne Grenzen und Route Behavior, das sich nicht aus einer Datei erklären lässt.
Der richtige Ansatz ist simpel: Wähle ein Lifecycle-Modell, halte die Pipeline kurz, trenne Routes nach Traffic-Typ, messe Latenz jeder Schicht, lies den Body nicht ohne Ownership und verstecke keine Business Rules in globaler Middleware.
Wenn du minimalen Overhead brauchst, schreibe native Komposition rund um Bun.serve. Wenn du einen vertrauten Middleware Flow willst, nimm Hono. Wenn du einen Bun-first typed lifecycle möchtest, schau dir Elysia an. In allen drei Fällen hängt Erfolg nicht vom Framework-Namen ab, sondern von Pipeline-Disziplin.
Natives `Bun.serve` erzwingt kein Express-style `.use()` Modell. Es arbeitet über einen `fetch` handler und `routes`, und Middleware in nativem Bun wird meist als Funktionskomposition rund um `Request`/`Response` geschrieben. Wenn du ein fertiges `.use()` Modell brauchst, nimm Hono; wenn du Lifecycle Hooks brauchst, schau dir Elysia an. [1][5][6]
Hono ist besser, wenn du ein simples Web Standards Middleware-Modell, Portability und einen vertrauten `.use()` Flow brauchst. Elysia ist besser, wenn du ein Bun-first Framework, typed context, validation und einen klaren Lifecycle willst. Native Bun ist besser für kleine oder sehr kontrollierte Services.
Am häufigsten verursachen body parsing, auth/session lookup, rate limiting mit remote storage, verbose logging, synchronous crypto/compression und Middleware Probleme, die global auf Routes läuft, wo sie nicht gebraucht wird.
Ja, aber vorsichtig. Der Body ist im Web API Modell ein Stream, deshalb sollte Middleware expliziter Owner des Parsing sein oder den parsed value im Context weitergeben. Lies den Body nicht in mehreren Schichten ohne Contract.
Trenne public/private/system/streaming routes, füge frühe cheap checks hinzu, zentralisiere das Error Format, logge keine Secrets, setze Payload Limits, nutze request id, teste early exits und messe Latenz jeder Schicht.
Nicht automatisch. Ein Teil der Middleware funktioniert über kompatible Frameworks oder Adapter, aber Express Middleware verlässt sich oft auf spezifische `req`/`res` Mutationen. Für eine neue Bun API sollte man zuerst ein native Bun-, Hono- oder Elysia-Modell wählen und dann nur wirklich nötige Schichten migrieren.
Die Quellen unten bestätigen API-Verhalten von Bun, Routes/Static Responses, Server Lifecycle Controls, das Hono Middleware Model und Elysia Lifecycle Hooks.
• 1. Bun docs - Server: `Bun.serve`, routes, fallback fetch, configuration, lifecycle methods
• 2. Bun docs - Routing: route precedence, type-safe params, static responses, file responses
• 3. Bun docs - Server idleTimeout and per-request `server.timeout(req, seconds)`
• 4. Bun docs - WebSockets: compression, backpressure, idle timeout, max payload length
• 5. Hono docs - Middleware guide: before/after handler, `await next()`, early response
• 8. Bun docs - Runtime options including `--max-http-header-size`
PAS7 Studio kann helfen, ein Bun Backend zu entwerfen, die Request Pipeline zu auditieren, Middleware nach Routes zu trennen und Observability, Security Baseline sowie Performance Checks hinzuzufügen.
Das ist besonders nützlich, wenn du von Express/Fastify migrierst, eine neue Bun API startest oder verstehen willst, wo genau Middleware Latenz und Risiken erzeugt.
Bun.js Middleware 2026: Overview, Best Practices und Anti-Patterns
Verwandte Artikel
AI Assistant Entwicklung Kosten 2026: RAG, Knowledge Base, Integrationen und Support
Praktischer Leitfaden zu Kosten fuer AI Assistants: RAG, Knowledge Base, Channels, Tool Use, Guardrails, Evaluations, Monitoring und Support.
KI fur Landingpage-Entwicklung: wo sie Launches beschleunigt und wo sie Conversion schadet
Eine praxisnahe Analyse zur Nutzung von KI fur Landingpages: v0, Webflow AI, Builder.io, Framer-ahnliche Builder, UX-Generierung, Copy, SEO, Personalisierung, A/B-Tests, Template-Risiken, Accessibility, Security und technischer Schuldenaufbau.
AI SEO / GEO im Jahr 2026: Ihre nächsten Kunden sind nicht Menschen — sondern Agents
Suche verschiebt sich von Klicks zu Antworten. Bots und AI-Agents crawlen, zitieren, empfehlen — und kaufen zunehmend. Erfahren Sie, was AI SEO / GEO bedeutet, warum klassisches SEO nicht mehr reicht und wie PAS7 Studio Marken im agentischen Web sichtbar macht.
Der leistungsstärkste Chip von Apple? M5 Pro und M5 Max brechen Rekorde
Eine Analyse zu Apple M5 Pro und M5 Max im März 2026. Wir zeigen, warum diese Chips als die stärksten professionellen Laptop-SoCs von Apple gelten können, wie sie sich gegen M4 Pro, M4 Max, M1 Pro, M1 Max schlagen und was der Vergleich mit aktuellen Intel- und AMD-Chips zeigt.
Professionelle Entwicklung für Ihr Geschäft
Wir erstellen moderne Web-Lösungen und Bots für Unternehmen. Erfahren Sie, wie wir Ihnen helfen können, Ihre Ziele zu erreichen.