Universal Cache Middleware with Storage Adapter Support

[lord007tn]

What is the feature you are proposing?

Problem

Hono's current cache middleware implementation has two key limitations:

• Platform-specific dependency (Cloudflare/Deno only)
• Lack of storage adapter support (Redis, Memory, Filesystem, etc.)

This forces developers to:

• Write custom caching solutions for Node.js/Bun environments
• Re-implement cache layers for different storage backends
• Maintain inconsistent caching patterns across projects

Proposal: Universal Cache Middleware

Implement a flexible caching system inspired by Nitro's cache implementation with:

Storage Adapter Interface

Support pluggable adapters for:

• Redis
• In-memory (default)
• Filesystem
• Cloudflare KV/Deno KV
• Custom implementations

Unified Configuration

// Global configuration
const app = new Hono({
  cache: {
    storage: 'redis',
    ttl: 3600,
    redisOptions: { ... }
  }
})

// Per-route configuration
app.get('/data', 
  cache({
    storage: 'memory',
    ttl: 60,
    vary: ['Authorization']
  }),
  handler
)

Core Features

• TTL management
• Cache-Control header synchronization
• Vary header support
• Cache key generation strategies
• Multi-platform support (Node, Bun, Deno, Cloudflare, etc.)

Why This Matters

• Framework Completeness: Modern frameworks like Next.js, Nuxt, and Astro include robust caching solutions. Hono needs equivalent capabilities to be considered production-ready for full-stack applications.
• Developer Experience: Reduce boilerplate for common caching patterns:

// Current workaround
let data
if (await cache.exists(key)) {
  data = await cache.get(key)
} else {
  data = normalDataRetriving()
  await cache.set(key, data)
}

Performance Critical

Proper caching is essential for:

• API response caching
• SSR/SSG optimizations
• Reducing expensive operations/API calls
• Platform Agnosticism

Aligns with Hono's core philosophy of universal compatibility across runtimes.

Implementation Considerations

Storage Adapter Interface Proposal

interface CacheStorage {
  get(key: string): Promise<Response | null>
  set(key: string, response: Response, options?: CacheOptions): Promise<void>
  delete(key: string): Promise<void>
}

Priority Adapters

• Memory (default)
• Redis (with popular clients)
• Filesystem (Node/Bun)
• Cloudflare KV

Other considerations:

• Automatic TTL handling from Cache-Control headers

[lord007tn]

@yusukebe @sor4chi
Would you please give your thoughts on this.
I am willing to implement it.
I have a basic implementation that I developed in our startup and maybe with your help, we can make it public.

[yusukebe]

Hi @lord007tn

Interesting!

However, I don't want to add more logic depending on each runtime to this honojs/hono. That will increase the package size and maintenance costs. It will be okay to provide a super thin API or a TypeScript interface. For example, make Cache Middleware so that the user can replace the cache method instead of Cache API's.

[lord007tn]

I am not sure i fully understand your idea. Could you provide for e.g a pseudo-code implementation so we can be on the same level.
also, we can do it on their middleware repo so it can be installed when needed.