Can we replace our caching mechanism with context.effect?

[PaulRBerg]

In our Sablier indexers, we are caching the token data so that we're not spamming the RPC with identical requests for the same token:

https://github.com/sablier-labs/indexers/tree/f23d7f309cf0b80466f39e815af938fc6286541e/apps/flow-envio/.cache

I was wondering if we can ditch that caching system and instead use the new context.effect API? Or, even when using context.effect, the caching system would be helpful still?

cc @DZakh, @razgraf

Related: sablier-labs/indexers#84 (comment)

[DZakh]

That's our final goal, but we are not there yet. You can definitely start using it together with loaders to optimise external calls performance, but you'll need to keep you cache persistence logic for some time.

In the next sprints, we aim to make the Effect API automatically persist all the calls and keep the data between reindexing. After it's shipped you'll be able to remove your custom solution.

[DZakh]

The current version also has a short-lived persistence, but it's only for a batch of events, which is usually 5000.

[PaulRBerg]

Amazing thanks for the quick answer, ser. We'll keep the caching logic for now, but I must confess it would be quite helpful (for maintenance cost) if we could remove it!

Maybe you can abstract away the cache for users who are using context.effect by keeping the cache in your backend somewhere? idk

[DZakh]

That's the plan 🫡
We originally wanted to start working on it this week, but plans changed in favor of a Solana spike 😁

[DZakh]

We haven't decided on how to store it in our backend. I'm curious about your feedback on what you think of using https://git-lfs.com for this? It should be possible to store the cache in the repo this way without additional auth.

[PaulRBerg]

thanks for the tip!