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.
Top comments (0)