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.

[nferreira1]

Hi @lord007tn and @yusukebe,
I'm very interested in this proposal too! I believe a universal cache middleware with adapter support would be an amazing addition to Hono.
I'm willing to help contribute to the development if needed — either with implementation, reviewing, or testing.
Please let me know how I can assist!

[yusukebe]

I think it will be better if we make it as third-party middleware like @hono/cache on https://github.com/honojs/middleware because we need to add tests using external libraries and middleware like Redis, Cloudflare KV, etc. We have to keep this honojs/hono repo small and does not depend on more external things. But making it on honojs/middleware will be okay.

[drag0n-app]

This is an excellent suggestion. The built-in Cache middleware should support Node.js and Bun environments to minimize differences. The default storage is an in-memory adapter, with support for Redis, Filesystem, and other storage adapters via third-party plugins.

[leonceaklin]

Why not building upon Unstorage https://unstorage.unjs.io/ for this? Maybe it even makes sense to adapt the same synax used in Nitro found at https://nitro.build/guide/cache.

[Pyakz]

+1

[Duzbee]

I am interested in this as well

[yusukebe]

I commented before: #3857 (comment). I think it's better to implement this into honojs/middleware as an independent package like @hono/universal-cache. If someone does, I'll review it.

[drag0n-app]

I commented before: #3857 (comment). I think it's better to implement this into honojs/middleware as an independent package like @hono/universal-cache. If someone does, I'll review it.

@lord007tn @nferreira1 Can you implement this feature?

[anasmohammed361]

Any updates on this guys?

[anasmohammed361]

https://github.com/anasmohammed361/hono-universal-cache

[anasmohammed361]

try this out and let me know if you have any thoughts on this .