标签：#bunjs

mqttkit: Elysia-style application framework for MQTT An ordered middleware pipeline, typed topic routes, MQTT 5 RPC, and auto-generated AsyncAPI docs — sitting on top of any MQTT broker. If you've ever built a serious MQTT backend in Node, you've probably written this code at least once: client . on ( ' message ' , ( topic , payload ) => { if ( topic . startsWith ( ' devices/ ' ) && topic . endsWith ( ' /events ' )) { const uid = topic . split ( ' / ' )[ 1 ] // ad-hoc auth check // ad-hoc JSON.parse + validation // ad-hoc error handling // ad-hoc metrics // ... } else if ( topic . startsWith ( ' server/ ' )) { // ... } }) That's the MQTT equivalent of writing an HTTP server with http.createServer((req, res) => { if (req.url === '/users') ... }) . We solved that pattern for HTTP a decade ago with Express, Koa, Fastify, and more recently Hono and Elysia. For MQTT, we haven't. That's the gap mqttkit is filling. The design choice: don't reimplement the protocol There are already excellent MQTT brokers in the Node ecosystem — most notably Aedes , which handles CONNECT, SUBSCRIBE, PUBLISH, QoS, retain, sessions, persistence, and MQTT-over-WebSocket. EMQX and Mosquitto cover production scale. None of these need replacing. What's missing is the application layer — the part where you ask: How do I declaratively say "this topic requires this auth check"? How do I validate payloads with the same schema I already use for HTTP? How do I do MQTT 5 request/response without writing correlation-id bookkeeping? How do I get AsyncAPI docs for free? How do I attach Prometheus / OpenTelemetry without lifting broker internals? mqttkit is purely that layer. It plugs into Aedes via @mqttkit/aedes , but the broker is just an adapter — you can write your own for EMQX, NanoMQ, or any other broker. What the code looks like import { aedes } from ' @mqttkit/aedes ' import { MqttApp , router } from ' @mqttkit/core ' import { z } from ' zod ' const app = new MqttApp < { principal ?: { uid : string

Bun is fast. The README will tell you 4x on bun install , 3-5x on Bun.serve() , 2x on bun:sqlite . Some of this matters for AI agents. Some of it doesn't. We've been running production agents on Bun for about 3 months — a mix of Hono-on-Bun HTTP agents and standalone Bun scripts called from Claude Code and OpenClaw. This post is what we'd tell ourselves 3 months ago about where Bun actually helps and where it bites. Where Bun's speed actually matters for agents Cold starts on agent scripts Agents are spawned. A lot. Every Claude Code hook, every npx invocation, every cron-fired worker. Node's startup is ~80-120ms cold; Bun's is ~15-25ms. For interactive agent loops where the user is waiting on a hook to populate context, that's a noticeable UX difference. The pre-task hook that takes 250ms to do its retrieval feels totally different when the runtime ate 100ms vs 20ms of that budget. This is the strongest case for Bun in agent workflows. Concrete win. bun install for ephemeral agent containers If you spin up containerized agents (Daytona, E2B, Modal, your own ECS task), each cold container does a package install. npm install on a fresh container is 30-90s; bun install is 5-15s. Over thousands of agent runs per day, that's real money. For Workers / serverless / persistent processes, this doesn't matter — you only install once. bun:sqlite for local agent memory If you're building a per-agent local cache (recent tool calls, recently-seen embeddings, scratchpad state), bun:sqlite is genuinely 2x faster than better-sqlite3 on simple selects. It's also zero-install — no native bindings to compile, no Python build chain, just import { Database } from 'bun:sqlite' . If your agent runs on a Bun runtime AND uses SQLite for state, the math works. If you're on Node, just use better-sqlite3 . Where Bun's "speed" doesn't matter LLM inference latency The agent is going to wait 800-4000ms for the LLM to respond. The 50ms of runtime overhead you saved is round-off. Your bottleneck is