tinkoff / cachalot Goto Github PK

Right now readThrough is called like this:

readThrough(
  cacheKey,
  async () => executor(...params),
  { tags },
);

Meaning that we need to know tags before executor call. But there are cases when tags depend on executor result

I suggest to add ability to pass getTags function to options which will be called after executor success and would have executorResult as its argument. getTags would return array of tags which will be added to other tags

here is an example

readThrough(
  cacheKey,
  async () => executor(...params),
  { tags, getTags: (executorResult) => [<additional tags>] },
);

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

• chore(deps): update dependency ioredis to v4.28.5 (ioredis, @types/ioredis)
• chore(deps): update dependency prettier to v2.8.8
• chore(deps): update dependency ts-jest to v27.1.5
• chore(deps): update dependency typescript to v4.9.5
• chore(deps): update jest monorepo (@types/jest, jest)
• chore(deps): update typescript-eslint monorepo to v4.33.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• chore(deps): update dependency eslint-config-prettier to v9
• chore(deps): update dependency prettier to v3
• chore(deps): update dependency typescript to v5
• chore(deps): update jest monorepo to v29 (major) (@types/jest, jest, ts-jest)
• chore(deps): update redis docker tag to v7
• chore(deps): update typescript-eslint monorepo to v6 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency @types/uuid to v8.3.4
• chore(deps): update semantic-release monorepo (@semantic-release/changelog, semantic-release)
• chore(deps): update dependency eslint-config-prettier to v8.10.0
• chore(deps): update actions/checkout action to v3
• chore(deps): update dependency @types/node to v18
• chore(deps): update dependency eslint to v8
• chore(deps): update dependency ioredis to v5
• chore(deps): update dependency semantic-release to v21
• chore(deps): update dependency uuid to v9 (uuid, @types/uuid)
• chore(deps): update github/codeql-action action to v2
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

First of all I want to congratulate you on this fantastic piece of code! Finally a conceptual approach that makes sense.

My thoughts:

I think today's systems need more like classic caches and your approach goes a lot further. I don't need a cache, I need a distributed memory manager. The problem at the moment is that the cache is always seen as an intermediate layer to data sources (DB, API) and a "cost / benefit" decision must always be made.

I think it should be easier! The cache should basically be the basis for storing data - and then, depending on the configuration, reduce latency and computing power in a distributed environment.

What is missing?

1. Multi-tier

• The cache should basically be multi-tier, whereby I would not overdo it (creating X adapters etc.)

• However, it must be possible to use an in-memory cache.

• Local memory is just FAST and today's servers really have enough of it.

• If the cache should be the basis, then you should also be able to use it for development or for small projects, where maybe there is no Redis (yet).

  In-memory cache with size limit and hit tracking for optimal garbadge collect

2. Invalidation - instead of TTL

• Our micro services receive events via a message broker and based on this information you can delete outdated data.
• Right now I see no direct delete methods - and they should also work based on tags and not limited to one key

3. Versioning - short round trip instead of TTL

• Internally you already work with versions
• It should be possible to ask Redis for newer version (based on given version from local in-memory cache)
• I created such a thing already with some little lua script injected to Redis, which just returns the data if a newer version exists.
• With that you have just one request and 5 byes response if your local data is still up2date

4. Pre-warm in memory cache

• In combination with a message brokers (or even Redis pubsub) it is also possible to cache data in-memory, before it gets accessed

• This logic is application side, but would a good interface would help.

  Refresh ahead is nice, but I want control over my data and not just statistical optimizations**

Right now we have many backends with some kind of "session stickyness", just to have some little information already there to improve latency. That sucks and with the possibilities described it would be easy to solve.

Maybe you have similar ideas? I would appreciate feedback and if you have a roadmap in which direction the project should go, I would be very interested!

Thanks a lot!

Nic