feat(indexer): Moar cache

[Yawning]

No description provided.

[ptrus]

Would adding one more cache for GetLogs (per round) make sense as well?

[codecov]

Codecov Report

Merging #244 (f7fc08e) into main (c5d8b86) will decrease coverage by 0.24%.
The diff coverage is 60.60%.

@@            Coverage Diff             @@
##             main     #244      +/-   ##
==========================================
- Coverage   58.12%   57.87%   -0.25%     
==========================================
  Files          25       26       +1     
  Lines        2985     3174     +189     
==========================================
+ Hits         1735     1837     +102     
- Misses       1069     1148      +79     
- Partials      181      189       +8     

Impacted Files	Coverage Δ
conf/config.go	41.07% <ø> (ø)
main.go	9.46% <0.00%> (ø)
indexer/backend_cache.go	35.23% <44.28%> (+8.41%)	⬆️
db/model/model.go	60.93% <60.93%> (ø)
indexer/backend.go	58.26% <100.00%> (-10.92%)	⬇️
indexer/indexer.go	46.19% <100.00%> (ø)
indexer/utils.go	75.65% <100.00%> (+3.75%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c5d8b86...f7fc08e. Read the comment docs.

[Yawning]

Would adding one more cache for GetLogs (per round) make sense as well?

In theory, yes. In practice, it depends on the access patterns, and how much work we want to put into it. The API doesn't help here, because GetLogs takes a range. If the state of the cache is pathologically sparse, then having a cache can end up using more database interactions than not having one.

My current inclination here is to wait till we have metrics on how often this is used, and what the requests look like. If requests like GetLogs(10, 10) is common, then I would not be opposed to special casing that.