[Enhancement Proposal] - Cache for route registration potentially grow infinitely during application time.

[kanin-kearpimy]

Hey @SaltyAom

I've found something interesting during application on Elysia is running.

As of my knowledge, Elysia has mechanism to cache interface initialisation such as router registration like below.

const cachedInference = caches[key]
if (cachedInference) {
	inference = mergeInference(inference, cachedInference)
	continue
}

That is totally great! So, we don't need to compute the whole interface again.

However, I noticed that when it come to cases like

app.get('/users/:id', () => {
  return ...
})

It's possible that :id which is dynamic and can grow infinitely will affect the cache size, so do memory consumption during Elysia runtime.

I'm not sure you think this is problem as of now, or you have something in mind to handle this in upcoming version.

I have a proposal for this.

1. Static Least Recently Used (LRU) to limit growing size of cache. We do have some scanner to remove LRU elements in cache. It may take a bit of computational power (we can handle it by timer, static max size of cache) to clean cache. However, we can save a lot of memory.

Please let me know what you think. If it sound good. I can open PR and let you review it.

Best,
(James) Kanin Kearpimy

[SaltyAom]

Hi @kanin-kearpimy, that's a good point!

However, I noticed that when it come to cases like

app.get('/users/:id', () => {
  return ...
})

It's possible that :id which is dynamic and can grow infinitely will affect the cache size, so do memory consumption during Elysia runtime.

I understand your concern, but this will not be the case

Suppose we have a code like this:

function thing({ params: { id } }) {
    return 'hello'
}

Sucrose uses an actual code of a function by using someFunction.toString() as a key to compute the checksum
This will always result in the same key, even if the parameter id is dynamic, as we only use the body function as the key, not the parameter

You can try logging content, and key in sucrose function, and invoke a handler with a different id, and it would log the same key, and content

So the cache is scaled with the total routes, and the lifecycle function that is used in Elysia

Even if the user accidentally causes an infinite loop, it's unlikely that the key will be different unless the user uses eval to generate a new function or code

Sucrose cache will then be cleared when the server starts with clearSucroseCache

However, you made a totally valid point on the time limit in case the user doesn't use .listen to start the server (I'll look into that myself as it's a little bit complex scenario, don't worry)