DEV Community: Shayan M Hussain

Run Express on Bun. Without the rewrite.

Shayan M Hussain — Wed, 11 Mar 2026 02:24:18 +0000

bunWay: Express Feel, Bun-Ready, 19 Built-In Middleware

Most teams don't avoid Bun because they dislike performance.

They avoid Bun because migration feels expensive:

new framework mental model,
rewritten middleware stack,
route-by-route uncertainty,
team retraining.

bunWay exists to remove that friction.

It gives you a Bun-native framework with the Express-style developer experience your team already knows.

What bunWay is

bunWay is a web framework for Bun with strong Express API compatibility:

same (req, res, next) handler style,
familiar routing patterns,
familiar middleware flow,
one package with 19 built-in middleware.

This is not about inventing a new style. It's about helping Express teams adopt Bun without feeling like they have to start from zero.

Why we built it

At JointOps, we kept seeing the same blocker:

"We want Bun, but we don't want to rewrite everything right now."

So we built bunWay for real migration constraints:

existing Express codebases,
business deadlines,
teams that need predictable rollouts.

Who bunWay is for

You should look at bunWay if:

your team already ships Express APIs,
you want to adopt Bun incrementally,
you want fewer moving parts in your middleware stack,
you want a familiar developer experience instead of a full framework reset.

You should validate first if:

you depend on niche Express internals,
you need strict Node.js runtime compatibility,
your app relies on uncommon behavior paths you haven't tested yet.

What you get out of the box

bunWay ships with 19 built-in middleware, including:

body parsing (json, urlencoded, text, raw)
security (helmet, csrf, hpp, rateLimit, cors)
auth/session (session, passport, cookieParser)
files/static (upload, serveStatic)
utilities (logger, compression, timeout, validate, errorHandler)

The point is simple: common API needs in one framework package.

Quick look

import bunway, { cors, helmet, logger } from "bunway";

const app = bunway();

app.use(bunway.json());
app.use(cors());
app.use(helmet());
app.use(logger("dev"));

app.get("/health", (req, res) => {
  res.json({ ok: true });
});

app.listen(3000);

If you already know Express, this should feel immediately familiar.

Migration mindset (short version)

bunWay is best used as an incremental migration path:

start with imports,
move route groups gradually,
validate behavior with tests,
keep shipping.

No forced rewrite sprint.

Final thought

bunWay is not a "look how fast" product.

It's a "remove excuses to try Bun" product for teams that value delivery confidence and familiar patterns.

If that sounds like your team, start small and evaluate it in one service. Please leave a star on repo ⭐️

Docs: https://bunway.jointops.dev
GitHub: https://github.com/JointOps/bunway
npm: https://www.npmjs.com/package/bunway
Discord: https://discord.gg/fTF4qjaMFT

bun add bunway

Built by the JointOps team. MIT licensed. Contributions welcome.

Redis Changed Its License. Here's How I Future-Proofed My Rate Limiter with Valkey and DragonflyDB.

Shayan M Hussain — Thu, 26 Feb 2026 01:50:21 +0000

If you're running a Node.js or Bun API in production, there's a good chance Redis is somewhere in your stack. And if you've been paying attention to the open source world over the past two years, you know that "just use Redis" isn't as simple as it used to be.

I maintain hitlimit, a rate limiting library for Node.js and Bun. This week I shipped v1.3.0 with first-class Valkey and DragonflyDB support. Here's why, and what the numbers look like.

The Redis Licensing Timeline

For 15 years, Redis was BSD-licensed. Use it however you want, no restrictions. Then things changed fast:

March 2024 — Redis switches from BSD to dual SSPL/RSAL. The goal: stop cloud providers (AWS, Google) from offering managed Redis without paying. The community reaction is immediate and hostile.
March 2024 — The Linux Foundation announces Valkey, a fork of Redis 7.2.4 under the BSD license. AWS, Google, Oracle, Ericsson, and Snap back it on day one.
April 2025 — One year later, DevClass reports that Redis has lost most of its external contributors.
May 2025 — Redis 8 adds AGPLv3 as a third license option. Antirez (the original creator) returns to help course-correct.
September 2024 — Percona's survey reports 83% of large enterprises have adopted or are actively exploring Valkey. Over 70% of Redis users cite the licensing change as motivation to seek alternatives.
2026 — Valkey reaches v9 with features Redis doesn't have. DragonflyDB, a high-performance Redis-compatible store, continues gaining ground.

The AGPL option is an improvement, but the trust damage was done. Valkey is at v9 with a thriving contributor base, and many teams aren't looking back.

What This Means for Your API

If your rate limiting relies on Redis, you now have licensing questions. Maybe they don't affect you today — AGPL might be fine for your use case. But if you're at a company with a legal team, or you ship software to customers, or you simply prefer not to think about it, Valkey and DragonflyDB eliminate those questions entirely.

Valkey: Linux Foundation project. BSD licensed. Same Redis protocol, same commands, same client libraries. Drop-in replacement.

DragonflyDB: Redis-compatible, optimized for multi-core. BSL licensed. Designed for high-throughput workloads.

Both work with ioredis. Both run the same Lua scripts. Both use the same port. The migration is boring — which is exactly what you want from infrastructure changes.

The Migration: Three Lines of Code

// Before — Redis
import { redisStore } from '@joint-ops/hitlimit/stores/redis'
const store = redisStore({ url: 'redis://localhost:6379' })

// After — Valkey (literally change the import)
import { valkeyStore } from '@joint-ops/hitlimit/stores/valkey'
const store = valkeyStore({ url: 'redis://localhost:6379' })

Under the hood, ValkeyStore and DragonflyStore run the exact same Lua pipeline as RedisStore. Same atomic INCR + conditional PEXPIRE in a single round-trip. Zero new logic, zero new failure modes.

-- The Lua script powering all three stores
local key = KEYS[1]
local windowMs = tonumber(ARGV[1])
local count = redis.call('INCR', key)
local ttl = redis.call('PTTL', key)
if ttl < 0 then
  redis.call('PEXPIRE', key, windowMs)
  ttl = windowMs
end
return {count, ttl}

The Benchmarks

I benchmark every store, every framework, every release. Here are the v1.3.0 distributed store numbers — the ones that actually matter when you're running multiple API instances behind a load balancer.

Test methodology: 50,000 iterations × 5 runs per scenario, 5,000 warmup iterations discarded. Node.js v24.4.1, Apple M1. All raw JSON results are in the benchmarks directory.

Redis vs Valkey vs DragonflyDB

Store	ops/sec	Avg Latency	p99 Latency	License
Valkey	6,879	145μs	250μs	BSD
Redis	6,733	164μs	266μs	RSAL/SSPL/AGPL
DragonflyDB	5,861	170μs	272μs	BSL
Postgres	3,491	286μs	608μs	PostgreSQL

Valkey and Redis are within measurement noise. Same protocol, same Lua scripts, same ioredis client underneath. The bottleneck is network round-trip time — ~150μs over localhost — not the datastore.

DragonflyDB is slightly slower for this workload because rate limiting uses simple single-key operations where Dragonfly's multi-core architecture doesn't kick in. Still well within production tolerance.

Postgres is roughly half the throughput — but 3,500 ops/sec is still far more than most APIs need, and if you're already running PG, it means zero extra infrastructure.

With Framework Middleware (Node.js)

Framework	Store	ops/sec	Avg Latency
Express	Redis	6,188	161μs
Express	Valkey	~6,200	~160μs
Hono	Redis	6,340	157μs
Fastify	Redis	5,272	189μs

Framework overhead is negligible when each operation spends ~150μs on a network round-trip. The store choice matters more than the framework choice at this layer.

Bun Distributed Performance

Store	ops/sec	Avg Latency
Valkey	6,075	164μs
Redis	6,984	143μs
DragonflyDB	6,008	166μs

Same story on Bun — all three stores are within noise for rate limiting workloads.

Choosing the Right Store

Store	ops/sec	Distributed?	License	Best for
Valkey	6,879	Yes	BSD	Multi-instance, no licensing questions
Redis	6,733	Yes	RSAL/SSPL/AGPL	Multi-instance, if AGPL works for you
DragonflyDB	5,861	Yes	BSL	Multi-instance, multi-core optimized
Postgres	3,491	Yes	PostgreSQL	Already running PG, no extra infra
SQLite	418,260	No	Public domain	Single instance, survives restarts

Full Example

import express from 'express'
import { createLimiter } from '@joint-ops/hitlimit'
import { valkeyStore } from '@joint-ops/hitlimit/stores/valkey'

const app = express()

const limiter = createLimiter({
  store: valkeyStore({ url: 'redis://localhost:6379' }),
  windowMs: 15 * 60 * 1000,  // 15 minutes
  limit: 100,
})

// Apply to all routes
app.use(limiter.express())

// Or different limits per route
const strictLimiter = createLimiter({
  store: valkeyStore({ url: 'redis://localhost:6379' }),
  windowMs: 60_000,
  limit: 10,
})

app.post('/api/login', strictLimiter.express(), (req, res) => {
  // 10 attempts per minute
})

app.get('/api/data', (req, res) => {
  // 100 requests per 15 minutes (from the global limiter)
})

app.listen(3000)

Works with Express, Fastify, Hono, NestJS, Bun.serve, and Elysia. Same API across all frameworks.

Why Dedicated Stores Instead of "Just Use the Redis Store"?

You can use the Redis store with Valkey and DragonflyDB — it works perfectly. But dedicated stores give you:

Clarity — valkeyStore() is more descriptive than redisStore() pointed at a Valkey instance
Discoverability — someone searching "valkey rate limiter" on npm actually finds it
Future-proofing — if Valkey or DragonflyDB ever diverge from Redis protocol, we have a clean abstraction point

Getting Started

# Node.js
npm install @joint-ops/hitlimit

# Bun
bun add @joint-ops/hitlimit-bun

~8KB core bundle (Node.js) / ~18KB (Bun). Tree-shakeable stores — you only pay for what you import. Zero runtime dependencies. MIT licensed.

GitHub: https://github.com/JointOps/hitlimit-monorepo

Has the Redis licensing situation changed any of your infrastructure decisions? I'd love to hear about it in the comments.

Six frameworks. Four storage backends. One import. Zero dependencies.

Shayan M Hussain — Sun, 22 Feb 2026 05:31:58 +0000

app.use(hitlimit({ limit: 100, window: '1m' }))

Same API everywhere. Express, Fastify, Hono, NestJS, Bun.serve, Elysia. No adapters to install. No framework-specific config. Just one package and you are done.

Every Framework, Same Code

// Express
import { hitlimit } from '@joint-ops/hitlimit'
app.use(hitlimit({ limit: 100, window: '1m' }))

// Fastify
import { hitlimit } from '@joint-ops/hitlimit/fastify'
await app.register(hitlimit, { limit: 100, window: '1m' })

// Hono
import { hitlimit } from '@joint-ops/hitlimit/hono'
app.use(hitlimit({ limit: 100, window: '1m' }))

// NestJS
import { HitLimitModule, HitLimitGuard } from '@joint-ops/hitlimit/nest'
@Module({
  imports: [HitLimitModule.register({ limit: 100, window: '1m' })],
  providers: [{ provide: APP_GUARD, useClass: HitLimitGuard }]
})
export class AppModule {}

// Bun.serve
import { hitlimit } from '@joint-ops/hitlimit-bun'
Bun.serve({ fetch: hitlimit({ limit: 100, window: '1m' }, handler) })

// Elysia
import { hitlimit } from '@joint-ops/hitlimit-bun/elysia'
new Elysia().use(hitlimit({ limit: 100, window: '1m' })).listen(3000)

Switch frameworks tomorrow. Your rate limiting code stays the same.

4 Storage Backends Built In

No extra packages. No separate installs. Pick the right store for your deployment and swap it in one line.

// Memory (default) - fastest, no setup
app.use(hitlimit({ limit: 100, window: '1m' }))

// SQLite - survives restarts
app.use(hitlimit({ store: sqliteStore({ path: './limits.db' }), ... }))

// Redis - distributed across instances
app.use(hitlimit({ store: redisStore({ url: process.env.REDIS_URL }), ... }))

// Postgres - use your existing database
app.use(hitlimit({ store: postgresStore({ pool }), ... }))

Start with memory on day one. Move to Postgres or Redis when you scale. Nothing else changes.

New in v1.2.0: PostgreSQL Store

Most teams already have Postgres running. Why add Redis just for rate limiting?

import { postgresStore } from '@joint-ops/hitlimit/stores/postgres'
import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })

app.use(hitlimit({
  limit: 100,
  window: '1m',
  store: postgresStore({ pool })
}))

One atomic query per request. Zero race conditions. Tables created automatically on first run. Named prepared statements for 30 to 40 percent lower latency. No new infrastructure to manage.

Fast

Node.js (10K unique IPs)
Memory       3.16M ops/s      316ns
SQLite       352K ops/s       2.8us
Redis        6.7K ops/s       149us
Postgres     3.0K ops/s       336us

Bun (10K unique IPs)
Memory       8.32M ops/s      120ns
bun:sqlite   325K ops/s       3.1us
Redis        6.7K ops/s       148us
Postgres     3.7K ops/s       273us

Peak: 12.38M ops/s on Bun. 4.83M ops/s on Node.js.

All benchmarks are open source. Clone the repo and run them on your hardware.

More Than a Counter

Tiered limits for free, pro and enterprise plans.
Auto ban repeat offenders after N violations.
Group limits for per-team or per-org quotas.
Skip rules for health checks, admins, internal routes.
Human readable windows like '15m', '1h', '1d' instead of milliseconds.

All built in. All zero dependencies.

Get Started

npm install @joint-ops/hitlimit    # Node.js
bun add @joint-ops/hitlimit-bun    # Bun

Docs | npm | Release notes

If it saves you time give it a star.

[Boost]

Shayan M Hussain — Mon, 02 Feb 2026 17:55:09 +0000

Building a REST API with bunWay in 10 Minutes

Ali ・ Feb 2

#bunjs #api #tutorial #beginners

One rate limiter for Express, NestJS, and Bun published

Shayan M Hussain — Tue, 27 Jan 2026 03:01:45 +0000

I got tired of installing different rate limiting packages for every framework.

Express? One package. NestJS? Different package. Bun? Good luck finding one.

So I built one that works everywhere:

hitlimit({ limit: 100, window: '15m' })

Same config. Express, NestJS, Bun, Elysia — doesn't matter.

What's in it

All the stores — Memory, SQLite, Redis
Tiered limits — Free/Pro/Enterprise built in, no manual routing
Human time windows — '15m' not 900000
Lightweight — ~7KB

Performance

I ran benchmarks. It's fast — competitive with or faster than the alternatives depending on the scenario. But realistically, rate limiting isn't your bottleneck unless you're at serious scale.

Benchmark scripts are in the repo if you want to verify.

Try it

npm install @joint-ops/hitlimit

# Bun
bun add @joint-ops/hitlimit-bun

GitHub · Docs

It's brand new. Would love feedback — what's missing? What would make this useful for your projects?