[Feature] Universal cache middleware with pluggable storage adapters (Redis, in-memory, Cloudflare KV)

[Sajith15]

What is the feature you are proposing?

Problem:

Issue #3857 correctly identifies that Hono's existing cache() middleware only works on Cloudflare Workers (via Cache API) and has no storage adapter support. Node.js and Bun apps must implement their own caching from scratch.

This is the single most-requested missing piece for teams using Hono in production on non-Cloudflare runtimes.

What I want to build:

A universal @hono/cache middleware with a storage adapter interface:

import { cache } from '@hono/cache';
import { RedisStore } from '@hono/cache/redis';
import { createClient } from 'redis';

const redis = createClient();
await redis.connect();

app.use('/api/*',
  cache({
    store: new RedisStore({ client: redis }),
    ttl: 60,                           // seconds
    keyGenerator: (c) => c.req.url,    // default: full URL
    vary: ['Authorization'],            // cache-bust on these headers
    condition: (c) => c.req.method === 'GET', // only cache GETs
  })
);

Adapters I'll build:

1. MemoryStore — in-process LRU cache (default, zero deps)
2. RedisStore — wraps redis or ioredis client (peer dep)
3. CloudflareKVStore — uses KV namespace (existing behavior, migrated to adapter)
4. BaseStore — abstract class for custom implementations

API contract:

interface CacheStore {
  get(key: string): Promise<CacheEntry | null>;
  set(key: string, entry: CacheEntry, ttlSeconds: number): Promise<void>;
  delete(key: string): Promise<void>;
}

Why not hono-rate-limiter's approach:

The community hono-rate-limiter shows there's demand for pluggable adapters. An officially maintained @hono/cache with the same adapter pattern would give Hono the production-ready caching story it's missing for Node.js/Bun deployments.

I'll submit a PR to honojs/middleware once the design is approved. Should this live in hono/cache (core) or @hono/cache (middleware repo)?

[Jr-14]

There's already a PR honojs/middleware#1764 in the works to merge this as a third party middleware