jointlytech / cache-candidate Goto Github PK

As of right now, our keepAlive flag allows our internal timers to clear and restart on every request, yet I think we should allow our devs to define a "refreshTTL" method of some sort to be called in order to warn the cache adapter to refresh.

Think Redis: We can't leverage its internal EX because of our usage of timer bombs.

Why don't we allow our plugins to preload/attach something on function wrap? I mean without it being called. Surely the payload will be smaller.

We should freeze our internal functions but the getDataCacheKey and the getExceedingAmount to prevent overriding from plugins.

The title explains itself I guess eheh
We could have a 30 secs timeframe filled with THOUSANDS of different parametrized function calls results. We should implement some sort of LRU with a size buffer and remove the oldest items.

As of the general discussion of 2023-01-27, we decided the following:

• Force all hooks executions inside internal functions
• Expose all those functions to our plugins

As such, as an example, our dependency keys plugin would directly call deleteDataCacheRecord instead of calling the cache adapter directly.

stale-while-revalidate and similars could be easily achieved both via options and via plugins.

Just a reminder: Check all timeouts are reffed or unreffed correctly.

I was thinking, as this will go Open Source at one point or another, to just move the decorator away from the main package and provide it as a different package.

Doing so will allow us to remove the experimental decorators parameter from tsconfig and proceed with a simple HOF.

The decorator will just have this package as a dependency and just wrap the target descriptor with a cacheCandidate HOF.

We should check our uuid generation speed. I did some work on hyperid and we could consider switching for it as it is a small dependency providing the fastest uid generation known in node.

Are we sure the interface we are exposing for the candidate is of the same type as the initial function?

We should allow devs to define a flag saying "please, don't use your internal timeout bombs because my cache adapter can handle it for me", warning they won't have access to related hooks and events.

We should bring in a generic cache adapter for situations in which memory and redis aren't the choice. Or maybe when you use a different redis lib (ioredis).

Starting from simple ones as a test launcher, I'd like to bring in some actions.

To have better data from clinic, and to be sure that clinic go throught all our codebase we shoud try to use the test suite js to feed clinic.

A plugin providing a Boolean or similar to disable cache. As an example of implementation , it could call the cache delete and/or empty the timeframe cache at every call

We should have a look at how much the library impacts the worst case scenario: where nothing is cached.

How much average time does the candidate need to execute?

I was thinking we could explicitly export variables in our index file so that we don't risk exposing something unwanted in the future.

What I'm thinking is, as an example, moving from export * from './lib' to export {cacheCandidate, CacheCandidate} from './lib'.

Anything against it?

What about a function similar to the candidate used to drop an entry from the data cache?

Related to branch feat/plugins-system

I know we made the decision of going sync to prevent performance burdens, yet our users could need it for one reason or another.
We should discuss it!

Allow a Generic to be passed to the cache candidate so that the resulting function can be typed correctly.

Our new plugin internals interface would allow us to build an awesome UI, we could even have a timeline tracking everything happening in our app at any given time!

Me and @rollsappletree agree we could create a plugin allowing to change the key allowing a function to return a new key string.
It could be usable in logging contexts where a crypted key as we provide isn't suitable.

We could rename it to something else as it seems it only works when keep alive is true.