Create cache.Interface implementations for popular cache engines

[ipinfo]

Create cache.Interface implementations for popular cache engines

[przmv]

Feel free to contact me directly, since I’ve already implemented a CLI app, that uses IPinfo API client and boltdb as a cache. It is used in production and is heavily tested. Petr Shevtsov

…

On 27 Oct 2020, at 04:05, Uman Shahzad ***@***.***> wrote:  Actually I correct myself, @pshevtsov - I see that if we created our own CLI having an on-disk cache with TTLs would be great to answer requests across multiple CLI calls. I'll contribute something for that fairly soon, since that use case has come up. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[UmanShahzad]

Is boltdb (now forked into bbolt) really used a cache engine? AFAIK it's writing to disk and don't think people would use it for this, so might not be worth the effort.

If anything, memcached should replace that on the list instead.

[przmv]

@UmanShahzad it depends on a use case. For web apps some in-memory cache would be an ideal solution, but not for CLI apps.

[UmanShahzad]

@pshevtsov I would think it's the other way around - CLI apps can play fast and loose with memory because they'll usually terminate before memory is an issue, and some web apps might want a really large cache so would do it on-disk to be safe from exhausting mem.

In any case, I agree that at least Redis/Memcached should be supported. Supporting bbolt sounds fine too but would put it last on the prio list.

[UmanShahzad]

Actually I correct myself, @pshevtsov - I see that if we created our own CLI having an on-disk cache with TTLs would be great to answer requests across multiple CLI calls.

I'll contribute something for that fairly soon, since that use case has come up.