[Feature] @hono/rate-limiter - official rate limiting middleware with Redis and memory backends

[Sajith15]

What is the feature you are proposing?

Problem:

Issue #1411 requests an officially maintained @hono/rate-limiter middleware, mirroring the community hono-rate-limiter library. The community library is good but having an official package in the @hono namespace matters for enterprise teams who can't use unsigned community packages.

What I want to build:

import { rateLimiter } from '@hono/rate-limiter';
import { RedisStore } from '@hono/rate-limiter/redis';

app.use('/api/*', rateLimiter({
  windowMs: 60_000,       // 1 minute window
  limit: 100,             // 100 requests per window
  keyGenerator: (c) => c.req.header('x-forwarded-for') ?? 'unknown',
  store: new RedisStore({ client: redis }),
  onLimitReached: (c) => c.json({ error: 'Rate limit exceeded' }, 429),
}));

Algorithms I'll support:

1. Fixed window (default — simplest, stateless counter per window)
2. Sliding window (Redis sorted set implementation — accurate, no burst at window boundary)
3. Token bucket (smooth rate limiting for burst-tolerant APIs)

Each algorithm is a separate store implementation so users can pick the right tradeoff.

Why official matters:

The honojs org publishing @hono/rate-limiter vs a community package signals that this is the blessed solution. Enterprise teams running Hono on Node.js (not just Cloudflare) need this. I'll follow the exact same adapter pattern as hono-rate-limiter for drop-in compatibility.

This is a companion to the @hono/cache issue I'm also proposing. They share the same Store adapter pattern. Should I submit them as one PR or separately?

[Jr-14]

Issue #1411 does not request an official maintained @hono/rate-limter wondering where this came from?

You can also definitely write your own rate limiting middleware if enterprise teams can't use unsigned community packages. 🤔

I'd also be weary vendor lock in like redis, when there are many other alternatives to in-memory key value stores. It will definitely be a maintenance burden.