contract.read.* cache layer

[jbrower95]

• It would be great to able to specify a cachePolicy to cache calls to contract.read.* in localStorage.
• I'm thinking that most apps i'd build on top of viem wouldn't want to be aggressively refetching against a node, as this is very wasteful for node credits. By the same hand, I don't quite need an indexer yet, for how simple my queries are.

e.g

const name = contract.read.getUsernameByAddress([myAddress], {cacheTTL: 60000})
`// fulfilled from node`
const name = contract.read.getUsernameByAddress([myAddress],  {cacheTTL: 60000})
`// fulfilled from cache`
`// .. wait 90 seconds`
const name = contract.read.getUsernameByAddress([myAddress],  {cacheTTL: 60000})
`// fulfilled from node`

• If I invoke the same function, with the same arguments in that period, it would be great to have an option to automatically cache. By default, invoking any .write(...) on a contract should probably just evict automatically. You could imagine that a programmer might listen for ethereum events, and trigger a cache eviction based on an event popping up.

e.g:
contract.evictCache()

FWIW -- I think all of this can be implemented today by overwriting readContract and writeContract in user-land, with some minor modifications.

Thoughts?

[jxom]

This can already be achieved (on the client) by wrapping Viem in an external caching layer like TanStack Query (they also have a Core API if you want Vanilla JS only, and also React/Vue/Svelte/Solid APIs). This is what our other library Wagmi does already, which uses Viem under the hood. This is more of a "higher-level" solution though.

From a "lower-level" perspective, I generally wonder if immutable resources like eth_call (on a block number/hash), eth_getBlockByNumber, eth_getTransactionByHash, would be better cached on the RPC via HTTP cache headers or KV storage. Caching in Local Storage isn't very reliable as you'll hit the 5MB quota quite fast if your application is heavy on eth_call, so you'll probably need to implement some LRU mechanism or something to mitigate.

[jbrower95]

Oh great, thanks for the info!!

[0x33dm]

cc @jxom

on the nerver i believe using node-cache can do the trick, still would be good to have some sort of RQuery on the server to dedup requets for instance. i wonder if that's possible.

Another feature from wagmi that could be interesting is something like "wagmi generate" to generate all the functions for instance

[sakulstra]

@jxom any idea how i could do this directly on the viem side without a layer on top.

I'd like to have a client instance that simply caches all queries forever.

[jxom]

You may want to check out Blutgang? https://github.com/rainshowerLabs/blutgang