A while ago, I kept running into the same problem.

I wanted a client-side cache that felt solid enough for real apps — not just a quick Map wrapper, and not something locked into one data-fetching library.

Most options were either:

  • too minimal
  • too framework-specific
  • or not very predictable once the app got bigger

So I tried a different approach.

Instead of keeping everything in JavaScript, I moved the cache engine into Rust and compiled it to WebAssembly.

That project became Blaze Cache.

The idea

The goal was not to replace JavaScript.

The goal was to put the performance-sensitive part in a tighter core:

  • storage
  • eviction
  • TTL tracking
  • tag indexing

Then keep the TypeScript layer thin for browser integration and adapters.

After initialization, reads and writes are synchronous. No Promises on the hot path.

What it became

Blaze Cache now includes:

  • SIEVE eviction
  • TTL support
  • tag-based invalidation
  • optional IndexedDB persistence
  • a typed event system
  • adapters for Axios, fetch, TanStack Query, and SWR

The design is simple:

one core, many adapters

Whether you use React Query, SWR, Axios, or plain fetch, they can share the same cache engine.

Why this was interesting to me

I wanted to see whether a Rust/Wasm core could make browser caching feel more structured and predictable, while still being practical for normal frontend work.

It also forced a lot of useful design questions:

  • What belongs in Wasm?
  • What should stay in JS?
  • How do you keep the API typed and ergonomic?
  • How do adapters share one engine without fighting each other?

Current status

Blaze Cache is at v0.2.5.

It’s still early, but the foundation is there:

  • a real Rust core
  • TypeScript bindings
  • persistence
  • multiple integrations
  • docs

Links

If you work with frontend performance, Wasm, or library design, I’d love feedback.